潛在場景如何?

當MySQL單表的數據量過大時，數據庫的訪問速度會下降，“數據量大”問題的常見解決方案是“水平切分”。

[[258671]]

MySQL常見的水平切分方案有哪些?

• 分庫分表;
• 分區表。

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

什么是分庫分表?

把一個很大的庫(表)的數據分到幾個庫(表)中，每個庫(表)的結構都相同，但他們可以分布在不同的MySQL實例，甚至不同的物理機器上，以達到降低單庫(表)數據量，提高讀寫性能的目的。

分庫分表有什么缺點?

分庫分表往往是業務層實施的，分庫分表后，往往需要升級系統：

• 修改某些SQL代碼;
• 喪失某些SQL功能。

什么是分區表?

所有數據，邏輯上還在一個表中，但物理上，可以根據一定的規則放在不同的文件中。這是MySQL5.1之后支持的功能，業務代碼無需改動。

分區表看上去很帥氣，為什么大部分互聯網公司不使用，而更多的選擇分庫分表來進行水平切分呢?

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

• 如果SQL不走分區鍵，很容易出現全表鎖;
• 在分區表實施關聯查詢，就是一個災難;
• 分庫分表，自己掌控業務場景與訪問模式，可控;分區表，工程師寫了一個SQL，自己無法確定MySQL是怎么玩的，不可控;

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

• DBA給OP埋坑，容易大打出手，造成同事矛盾;
• …

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

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

希望這一分鐘有收獲。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文