如題，在mysql中，分表查詢和索引查詢那種方式更快？

喲喲認為查詢速度的快慢要針對於表裡資料的多少來定，並且分表查詢時也要將索引引入才能更快的將目標資料進行鎖定，單純的來對比分表查詢和索引查詢的話，個人感覺索引查詢相對比要快一些。

在mysql中為什麼會建立多個表呢？

這是因為在龐大資料量儲存時，建立多個表可以將資料進行均勻的分佈，每一個表內對應單獨的一項資料，查詢或呼叫時可以方便調取；若沒有分表的話，所有的資料可能存在一個表中，在寫入或查詢調取時會增加資料庫的負擔，延長查詢時間，增加磁碟的IO，因此針對大資料量儲存時最好建立不同類別的表，可以更方便更快捷的寫入並調取。

不論是分表查詢還是單表查詢一定要引入索引，這樣才能更快的定位目標資料。

因此喲喲認為，在資料量很大的情況下，建議分表+索引查詢可能速度更快，若資料量很小的情況下，直接索引查詢即可。

查詢快慢主決的因素有很多，儲存碎片、資料量大屬於I/O類問題；表結構設計、查詢語句屬於技術是否熟練（經驗）問題。對於你的分錶快還是索引快的這個問題本身就是有問題的：

在建立資料表的時候，索引是必須的，主鍵就是唯一索引，

我認為需要關注查詢快慢的時候，必定是單表資料量越來越大，或是已預見資料量會越來越大，例如日誌表、流水記錄等，要不就是查詢時關聯的表比較多。

如果是像配置類資料表資料量有限的表，加不加除了主鍵以外索引影響不大。

基於單資料庫來說，

那麼資料量大，增速快的表要想加查詢速度的首先索引是必須的，再加上分割槽或是分表才能有效的提升效率，有必要還可以做讀寫分離，

但是在做分表時怎麼分就要講究了，分表可以按欄位（縱向）分，也可以按某（些）欄位的值特性（橫向）去分，總之要儘量達到在同一分表中的資料特性相同，在生成SQL時，程式碼可以決定向哪幾個分表查，達到避免查詢無關的分表，查詢的表越少，需要掃描的記錄越少，效率肯定越高，如果達不到減少讀表和記錄的話，分表不但不會變快，反而變慢。

當然索引快，沒有索引要線性搜尋，如果記錄靠後幾乎是全表搜尋。理論上只要有索引，搜尋速度跟記錄數沒有關係，索引是一張獨立的HASH表。但記錄數多的時候，寫入索引會變慢。

分表呢只是解決表文件大小問題，和索引不是一回事，而且MYSQL有分割槽表功能，不用手工維護分表。

分表和索引並不是二選一的問題

通常使用MySQL時（其餘的資料庫也一樣），大多數時候索引是必須要增加的，好處是查詢速度提升非常大，資料量越多越明顯；缺點是會對新增、修改、刪除的速度造成一定程度的影響，不過這個影響和查詢效率的提升相比，不值一提。

當單表中的資料量進一步增多，例如到了大幾千萬、幾億這個級別，單臺MySQL已經不足以支撐這麼多的資料了，這時候就要考慮分割槽、分表或分庫了；當然分表之後，每一個子表中仍然可以有索引。

如果非要說分表查詢和索引查詢哪個快，當資料量沒達到需要分表的程度時，比如只有一百萬的資料量，我覺得還是索引查詢快，畢竟分表查詢還需要程式路由到資料所在的分割槽上，這個也是需要消耗時間的。

MySQL單表資料量在一千萬以內的時候，效能是比較好的，超過千萬效能會有下降，到了五六千萬以上，效能下降就比較明顯了，這是就要考慮分表了。

分表另外一個好處是，單個伺服器的效能畢竟是有限的，例如磁碟的IO，分表後將子表部署在不同的磁碟上（也可以直接分庫），可以利用多臺伺服器的資源，更好地支援高併發。

RANGE分割槽：根據某一個欄位的區間，進行分割槽。比如按照id分割槽，1到10萬一個分割槽，10萬零1到20萬一個分割槽。

HASH分割槽：定義一個表示式，對錶達式的結果進行分割槽選擇。例如把id和某個整數進行取模運算，結果為1的是一個分割槽，結果是2的一個分割槽。

業務欄位分割槽：這個就容易理解了，在業務資料中選擇一個合適的欄位，作為分割槽欄位。比如按照公司碼分割槽，companyCode=1（北京）為一個分割槽，companyCode=2（天津）為一個分割槽；當然，一般不會選擇companyName=北京/天津這樣的欄位；不過這種分表策略，不能保證資料平均，比如北京有五千萬資料，天津有五百萬資料。

分表/分庫雖然看起來很美好，但是問題也不少：跨庫關聯、分散式事務、結果集合並/排序等問題，都是需要考慮解決的。