問答專欄Q & A COLUMN
“我是喲喲吼說科技，專注于數(shù)據(jù)網(wǎng)絡(luò)的回答，歡迎大家與我交流數(shù)據(jù)網(wǎng)絡(luò)的問題”
如題，在mysql中，分表查詢和索引查詢那種方式更快？
喲喲認(rèn)為查詢速度的快慢要針對(duì)于表里數(shù)據(jù)的多少來定，并且分表查詢時(shí)也要將索引引入才能更快的將目標(biāo)數(shù)據(jù)進(jìn)行鎖定，單純的來對(duì)比分表查詢和索引查詢的話，個(gè)人感覺索引查詢相對(duì)比要快一些。
在mysql中為什么會(huì)建立多個(gè)表呢？
這是因?yàn)樵邶嫶髷?shù)據(jù)量存儲(chǔ)時(shí)，建立多個(gè)表可以將數(shù)據(jù)進(jìn)行均勻的分布，每一個(gè)表內(nèi)對(duì)應(yīng)多帶帶的一項(xiàng)數(shù)據(jù)，查詢或調(diào)用時(shí)可以方便調(diào)?。蝗魶]有分表的話，所有的數(shù)據(jù)可能存在一個(gè)表中，在寫入或查詢調(diào)取時(shí)會(huì)增加數(shù)據(jù)庫(kù)的負(fù)擔(dān)，延長(zhǎng)查詢時(shí)間，增加磁盤的IO，因此針對(duì)大數(shù)據(jù)量存儲(chǔ)時(shí)最好建立不同類別的表，可以更方便更快捷的寫入并調(diào)取。
不論是分表查詢還是單表查詢一定要引入索引，這樣才能更快的定位目標(biāo)數(shù)據(jù)。
因此喲喲認(rèn)為，在數(shù)據(jù)量很大的情況下，建議分表+索引查詢可能速度更快，若數(shù)據(jù)量很小的情況下，直接索引查詢即可。
歡迎大家多多關(guān)注我，在下方評(píng)論區(qū)說出自己的見解。
評(píng)論0
加載中...
通常使用MySQL時(shí)（其余的數(shù)據(jù)庫(kù)也一樣），大多數(shù)時(shí)候索引是必須要增加的，好處是查詢速度提升非常大，數(shù)據(jù)量越多越明顯；缺點(diǎn)是會(huì)對(duì)新增、修改、刪除的速度造成一定程度的影響，不過這個(gè)影響和查詢效率的提升相比，不值一提。
當(dāng)單表中的數(shù)據(jù)量進(jìn)一步增多，例如到了大幾千萬(wàn)、幾億這個(gè)級(jí)別，單臺(tái)MySQL已經(jīng)不足以支撐這么多的數(shù)據(jù)了，這時(shí)候就要考慮分區(qū)、分表或分庫(kù)了；當(dāng)然分表之后，每一個(gè)子表中仍然可以有索引。
如果非要說分表查詢和索引查詢哪個(gè)快，當(dāng)數(shù)據(jù)量沒達(dá)到需要分表的程度時(shí)，比如只有一百萬(wàn)的數(shù)據(jù)量，我覺得還是索引查詢快，畢竟分表查詢還需要程序路由到數(shù)據(jù)所在的分區(qū)上，這個(gè)也是需要消耗時(shí)間的。
MySQL單表數(shù)據(jù)量在一千萬(wàn)以內(nèi)的時(shí)候，性能是比較好的，超過千萬(wàn)性能會(huì)有下降，到了五六千萬(wàn)以上，性能下降就比較明顯了，這是就要考慮分表了。
分表另外一個(gè)好處是，單個(gè)服務(wù)器的性能畢竟是有限的，例如磁盤的IO，分表后將子表部署在不同的磁盤上（也可以直接分庫(kù)），可以利用多臺(tái)服務(wù)器的資源，更好地支持高并發(fā)。
RANGE分區(qū)：根據(jù)某一個(gè)字段的區(qū)間，進(jìn)行分區(qū)。比如按照id分區(qū)，1到10萬(wàn)一個(gè)分區(qū)，10萬(wàn)零1到20萬(wàn)一個(gè)分區(qū)。
HASH分區(qū)：定義一個(gè)表達(dá)式，對(duì)表達(dá)式的結(jié)果進(jìn)行分區(qū)選擇。例如把id和某個(gè)整數(shù)進(jìn)行取模運(yùn)算，結(jié)果為1的是一個(gè)分區(qū)，結(jié)果是2的一個(gè)分區(qū)。
業(yè)務(wù)字段分區(qū)：這個(gè)就容易理解了，在業(yè)務(wù)數(shù)據(jù)中選擇一個(gè)合適的字段，作為分區(qū)字段。比如按照公司碼分區(qū)，companyCode=1（北京）為一個(gè)分區(qū)，companyCode=2（天津）為一個(gè)分區(qū)；當(dāng)然，一般不會(huì)選擇companyName=北京/天津這樣的字段；不過這種分表策略，不能保證數(shù)據(jù)平均，比如北京有五千萬(wàn)數(shù)據(jù)，天津有五百萬(wàn)數(shù)據(jù)。
分表/分庫(kù)雖然看起來很美好，但是問題也不少：跨庫(kù)關(guān)聯(lián)、分布式事務(wù)、結(jié)果集合并/排序等問題，都是需要考慮解決的。
評(píng)論0
加載中...
謝謝邀請(qǐng)！
查詢快慢主決的因素有很多，存儲(chǔ)碎片、數(shù)據(jù)量大屬于I/O類問題；表結(jié)構(gòu)設(shè)計(jì)、查詢語(yǔ)句屬于技術(shù)是否熟練（經(jīng)驗(yàn)）問題。對(duì)于你的分表快還是索引快的這個(gè)問題本身就是有問題的：
在建立數(shù)據(jù)表的時(shí)候，索引是必須的，主鍵就是唯一索引，
我認(rèn)為需要關(guān)注查詢快慢的時(shí)候，必定是單表數(shù)據(jù)量越來越大，或是已預(yù)見數(shù)據(jù)量會(huì)越來越大，例如日志表、流水記錄等，要不就是查詢時(shí)關(guān)聯(lián)的表比較多。
如果是像配置類數(shù)據(jù)表數(shù)據(jù)量有限的表，加不加除了主鍵以外索引影響不大。
基于單數(shù)據(jù)庫(kù)來說，
那么數(shù)據(jù)量大，增速快的表要想加查詢速度的首先索引是必須的，再加上分區(qū)或是分表才能有效的提升效率，有必要還可以做讀寫分離，
但是在做分表時(shí)怎么分就要講究了，分表可以按字段（縱向）分，也可以按某（些）字段的值特性（橫向）去分，總之要盡量達(dá)到在同一分表中的數(shù)據(jù)特性相同，在生成SQL時(shí)，代碼可以決定向哪幾個(gè)分表查，達(dá)到避免查詢無關(guān)的分表，查詢的表越少，需要掃描的記錄越少，效率肯定越高，如果達(dá)不到減少讀表和記錄的話，分表不但不會(huì)變快，反而變慢。
即時(shí)原創(chuàng)回答，個(gè)人的一些體驗(yàn)，僅供參考！
評(píng)論0
加載中...
當(dāng)然索引快，沒有索引要線性搜索，如果記錄靠后幾乎是全表搜索。理論上只要有索引，搜索速度跟記錄數(shù)沒有關(guān)系，索引是一張獨(dú)立的HASH表。但記錄數(shù)多的時(shí)候，寫入索引會(huì)變慢。
分表呢只是解決表文件大小問題，和索引不是一回事，而且MYSQL有分區(qū)表功能，不用手工維護(hù)分表。
評(píng)論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
