Mysql-InnoDB分表真的有意義嗎?

12-29

分表可以減少鎖表的時間：
但是innodb本身就是行鎖，修改一條記錄不會互斥另外的操作，那麼在InnoDB引擎下，水平或垂直分表還有意義嗎?

分表加快檢索速度：
假如有100W行記錄，如果查找 where id = 900000,那麼資料庫會從100W里遍歷，如果垂直分表100個，就可以直接到第90個表裡找，資料庫只會遍歷1W個數據，但是真的是這樣嗎？這麼淺顯的優化資料庫本身難道沒做嗎？分表在InnoDB的情況下會不會是一廂情願？

公子所言更加接近是對mysql分區的特點描述而不是分表。

分表在數據量小的時候，並發查詢較低的時候完全沒有任何優勢可言。

sql查詢九成九都是隨機讀寫，並發性能是比較低的，要增加並發性能，多表策略行之有效，WP自己的伺服器就是每個庫4096個表.

分表相當於在查詢前面放了一個dispatcher,用來僅僅作為分配任務的角色，之前是每來一個查詢任務，每個線程/人都跑到一個倉庫裡面找，出現競爭條件的時候/鎖，就需要排隊了；分表之後一個大的倉庫相當於分成了多個小倉庫，這個分配任務的規則總是知道這個查詢應該在哪個小倉庫尋找，搜索範圍幾何級縮小。

如果分辨在應用層做，雖然編碼稍顯蛋疼，但是效能更高。

一般而言，相比於分表的坑，運維的難度，得到的性能收益，1.5TB 以內數據，排名250以後的網站對分表都沒有需求

Innodb並非所有操作都是行級鎖，行級鎖時分表分區的優勢就體現出來了，但是在掃描全表/總行數/模糊查詢/非索引查詢時，分表並沒有太多優勢，這種情況，分區到不同磁碟分散IO來加速更加實在。

-------------------------------------------

另外，如何優化 "快速找到女朋友" 的方法道理並不淺顯。1-24位女嘉賓，你說uid=18號，馬上就能找到，但是你說 where 顏值&>60 and CUP = C and 年齡 between 18 and 24 order by money,猜猜看需要查詢多少次呢？

但是如果你按照顏值分成10個表，再查詢呢？這就是預分表的威力了.

當然，按照年齡分表也類似，如何最初縮到最小範圍這是另外的話題了。

有

一般來說分表適用性很受限，分表能搞定的都是小系統，真正需要的是分伺服器( 實例級)。從你問話的問題來說，你們公司顯然沒有DBA，要不早都給你解答了，先找個懂資料庫的員工吧，要不你們系統是沒有什麼可運維的能力。

分表不一定是按照ID均分，有很多分法。

分表會增加代碼複雜度。

你可以先在心裡想好分表預案，等業務到一定量級，其它索引參數都優化了還有瓶頸，你就自然會去分表了。

Dba黔驢技窮了，能優化的都優化了，只剩這招了

你這個例子不太適當。因為where中的條件是主鍵，所以它其實掃描的是B+樹的索引，那麼掃描索引的效率主要和B+樹的高度相關，分表樹的高度會小一些，不分則高一些。但是因為索引樹一般最高也就3,4層，所以這種情況，分不分表對性能影響不是很大。真正影響巨大的是全表掃描的情況，在不分表的情況下，Mysql就真的沒有辦法像你說的那樣只掃描一小部分，他會全表掃描。

分表的可以避免hot page，防止並發插入引起latch～

分表並不一定是按照id

如果id作為主鍵，分表會用其他屬性～

你說的加鎖只是資料庫層面的加鎖

在操作系統層，還有一層自旋鎖～

建議新項目都用Innodb；歷史的能改用Innodb就改……

Innodb 的行級鎖只是對使用索引作為條件的有效，其他的對整張表的操作和使用非索引依舊是需要鎖表。