互聯(lián)網(wǎng)公司為啥都不用MySQL分區(qū)表?
潛在場景如何?
當(dāng)MySQL單表的數(shù)據(jù)量過大時(shí),數(shù)據(jù)庫的訪問速度會下降,“數(shù)據(jù)量大”問題的常見解決方案是“水平切分”。
MySQL常見的水平切分方案有哪些?
- 分庫分表;
- 分區(qū)表。
畫外音:我C,沒聽過分區(qū)表,有朋友驚嘆。
什么是分庫分表?
把一個很大的庫(表)的數(shù)據(jù)分到幾個庫(表)中,每個庫(表)的結(jié)構(gòu)都相同,但他們可以分布在不同的MySQL實(shí)例,甚至不同的物理機(jī)器上,以達(dá)到降低單庫(表)數(shù)據(jù)量,提高讀寫性能的目的。
分庫分表有什么缺點(diǎn)?
分庫分表往往是業(yè)務(wù)層實(shí)施的,分庫分表后,往往需要升級系統(tǒng):
- 修改某些SQL代碼;
- 喪失某些SQL功能。
什么是分區(qū)表?
所有數(shù)據(jù),邏輯上還在一個表中,但物理上,可以根據(jù)一定的規(guī)則放在不同的文件中。這是MySQL5.1之后支持的功能,業(yè)務(wù)代碼無需改動。
分區(qū)表看上去很帥氣,為什么大部分互聯(lián)網(wǎng)公司不使用,而更多的選擇分庫分表來進(jìn)行水平切分呢?
分區(qū)表的一些缺點(diǎn),是大數(shù)據(jù)量,高并發(fā)量的業(yè)務(wù)難以接受的:
- 如果SQL不走分區(qū)鍵,很容易出現(xiàn)全表鎖;
- 在分區(qū)表實(shí)施關(guān)聯(lián)查詢,就是一個災(zāi)難;
- 分庫分表,自己掌控業(yè)務(wù)場景與訪問模式,可控;分區(qū)表,工程師寫了一個SQL,自己無法確定MySQL是怎么玩的,不可控;
畫外音:類似于,不要把業(yè)務(wù)邏輯實(shí)現(xiàn)在存儲過程,用戶自定義函數(shù),觸發(fā)器里,而要實(shí)現(xiàn)在業(yè)務(wù)代碼里一樣。
- DBA給OP埋坑,容易大打出手,造成同事矛盾;
- …
當(dāng)然,在數(shù)據(jù)量和并發(fā)量不太大,或者按照時(shí)間來存儲冷熱數(shù)據(jù)或歸檔數(shù)據(jù)的一些特定場景下,分區(qū)表還是有上場機(jī)會的。
畫外音:例如,按照時(shí)間分區(qū),存儲日志。
希望這一分鐘有收獲。
【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件,轉(zhuǎn)載請聯(lián)系原作者】