一分鐘系列
潛在場景如何？
當MySQL單表的數(shù)據(jù)量過大時丙者，數(shù)據(jù)庫的訪問速度會下降营密，“數(shù)據(jù)量大”問題的常見解決方案是“水平切分”。
MySQL常見的水平切分方案有哪些评汰？
（1）分庫分表；
（2）分區(qū)表主儡。
畫外音：我C惨缆，沒聽過分區(qū)表，有朋友驚嘆寂汇。
什么是分庫分表畅蹂？
把一個很大的庫（表）的數(shù)據(jù)分到幾個庫（表）中，每個庫（表）的結(jié)構(gòu)都相同液斜，但他們可以分布在不同的MySQL實例，甚至不同的物理機器上臼膏，以達到降低單庫（表）數(shù)據(jù)量示损，提高讀寫性能的目的。
分庫分表有什么缺點检访？
分庫分表往往是業(yè)務(wù)層實施的脆贵，分庫分表后，往往需要升級系統(tǒng)：
（1）修改某些SQL代碼卖氨；
（2）喪失某些SQL功能负懦。
什么是分區(qū)表柏腻？
所有數(shù)據(jù)，邏輯上還在一個表中颗品，但物理上贫导，可以根據(jù)一定的規(guī)則放在不同的文件中蟆盹。這是MySQL5.1之后支持的功能，業(yè)務(wù)代碼無需改動峰档。
分區(qū)表看上去很帥氣寨昙，為什么大部分互聯(lián)網(wǎng)公司不使用，而更多的選擇分庫分表來進行水平切分呢舔哪？
分區(qū)表的一些缺點，是大數(shù)據(jù)量抬驴，高并發(fā)量的業(yè)務(wù)難以接受的：
（1）如果SQL不走分區(qū)鍵缆巧，很容易出現(xiàn)全表鎖；
（2）在分區(qū)表實施關(guān)聯(lián)查詢题暖，就是一個災(zāi)難捉超；
（3）分庫分表，自己掌控業(yè)務(wù)場景與訪問模式拼岳，可控；分區(qū)表侧啼，工程師寫了一個SQL，自己無法確定MySQL是怎么玩的痊乾，不可控；
畫外音：類似于哪审，不要把業(yè)務(wù)邏輯實現(xiàn)在存儲過程蛾魄，用戶自定義函數(shù)，觸發(fā)器里湿滓，而要實現(xiàn)在業(yè)務(wù)代碼里一樣滴须。
（4）DBA給OP埋坑，容易大打出手叽奥，造成同事矛盾扔水；
（5）…
當然，在數(shù)據(jù)量和并發(fā)量不太大朝氓，或者按照時間來存儲冷熱數(shù)據(jù)或歸檔數(shù)據(jù)的一些特定場景下魔市，分區(qū)表還是有上場機會的。
畫外音：例如赵哲，按照時間分區(qū)待德，存儲日志枫夺。
希望這一分鐘有收獲将宪。
