網際網路公司為啥都不用MySQL分區表？

潛在場景如何？

當MySQL單表的資料量過大時，資料庫的通路速度會下降，“資料量大”問題的常見解決方案是“水準切分”。 

MySQL常見的水準切分方案有哪些？

（1）分庫分表；

（2）分區表。

畫外音：我C，沒聽過分區表，有朋友驚歎。

 什麼是分庫分表？

把一個很大的庫（表）的資料分到幾個庫（表）中，每個庫（表）的結構都相同，但他們可以分布在不同的MySQL執行個體，甚至不同的實體機器上，以達到降低單庫（表）資料量，提高讀寫性能的目的。

分庫分表有什麼缺點？

分庫分表往往是業務層實施的，分庫分表後，往往需要更新系統：

（1）修改某些SQL代碼；

（2）喪失某些SQL功能。

 什麼是分區表？

所有資料，邏輯上還在一個表中，但實體上，可以根據一定的規則放在不同的檔案中。這是MySQL5.1之後支援的功能，業務代碼無需改動。

 分區表看上去很帥氣，為什麼大部分網際網路公司不使用，而更多的選擇分庫分表來進行水準切分呢？

分區表的一些缺點，是大資料量，高并發量的業務難以接受的：

（1）如果SQL不走分區鍵，很容易出現全表鎖；

（2）在分區表實施關聯查詢，就是一個災難；

（3）分庫分表，自己掌控業務場景與通路模式，可控；分區表，工程師寫了一個SQL，自己無法确定MySQL是怎麼玩的，不可控；

畫外音：類似于，不要把業務邏輯實作在存儲過程，使用者自定義函數，觸發器裡，而要實作在業務代碼裡一樣。

（4）DBA給OP埋坑，容易大打出手，造成同僚沖突；

（5）…

當然，在資料量和并發量不太大，或者按照時間來存儲冷熱資料或歸檔資料的一些特定場景下，分區表還是有上場機會的。

畫外音：例如，按照時間分區，存儲日志。

希望這一分鐘有收獲。

本文轉自“架構師之路”公衆号，58沈劍提供。