網際網路公司為啥都不用MySQL分割槽表?

58沈劍 發表於 2022-12-06
MySQL

潛在場景如何?

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

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

(1)分庫分表;

(2)分割槽表。

畫外音:我C,沒聽過分割槽表,有朋友驚歎。

什麼是分庫分表?

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

分庫分表有什麼缺點?

分庫分表往往是業務層實施的,分庫分表後,往往需要升級系統:

(1)修改某些SQL程式碼;

(2)喪失某些SQL功能。

什麼是分割槽表?

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

分割槽表看上去很帥氣,為什麼大部分網際網路公司不使用,而更多的選擇分庫分表來進行水平切分呢?

分割槽表的一些缺點,是大資料量,高併發量的業務難以接受的:

(1)如果SQL不走分割槽鍵,很容易出現全表鎖;

(2)在分割槽表實施關聯查詢,就是一個災難;

(3)分庫分表,自己掌控業務場景與訪問模式,可控;分割槽表,工程師寫了一個SQL,自己無法確定MySQL是怎麼玩的,不可控;

畫外音:類似於,不要把業務邏輯實現在儲存過程,使用者自定義函式,觸發器裡,而要實現在業務程式碼裡一樣。

(4)DBA給OP埋坑,容易大打出手,造成同事矛盾;

(5)…

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

畫外音:例如,按照時間分割槽,儲存日誌。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31556838/viewspace-2674666/,如需轉載,請註明出處,否則將追究法律責任。