在面試時被問到，為什麼MySQL資料庫資料量大了要進行分庫分表？

1樓：

這個問題就問的很沒有水平，

稍微有點基礎的人都知道是因為大資料了會導致查詢速度變慢與其這樣問不如問問為什麼大資料量的時候查詢速度會變慢，這樣至少可以知道求職者對於資料庫儲存方式和索引原理的知識了解多少。

2樓：wubx

知乎er的回答都非常精采。我比較好奇你們怎麼可以用這麼大的篇幅回答這個問題，得碼多久的字啊。

對於分庫分表這個MySQL的方案，說真的，我覺的是乙個病態的方案，這裡我也談一些我的想法。首先在知數堂的課程，我們也用乙個節課大概2個小時來講解了分庫分表。這裡我談一些我的想法。

大概分這四點：

現在MySQL中單錶10億左右的資料，物理大小100-200G，在OLATP中處理起來基本都不是事了。以前在處理的資料庫遷移專案中，一對一遷移，核心表經常過5億，也沒使用分割槽，那為什麼還要分？

是不是所有的業務都需要上來就分庫分表？

如果必須分庫分表分多少合適？

有沒有可替代的方案？

首先第乙個問題。我覺的分庫分表，一方面是為了效能，另一方面是為了管理。現在來看，分表，分割槽都是為了更好的管理資料庫。

對於這種超級大表，如果加欄位，加索引，或是單錶的資料一致性校驗，備份之類的，隨便乙個動作，都會對系統衝擊比較大。所以需要拆分。如果你們還把MySQL停留在單錶過1千萬，就效能下降，那需要更新一下知識了，了解一下MySQL8.

0的知識體系。

第二個問題：我的建議是能不分先不要分。對於使用MySQL8.

0的朋友，可以優先考慮分割槽。使用分表的目的為了不把雞蛋放在乙個籃子裡，讓資料拆分到不同的機器上，更多的是為了提高資料的可用性。或是做多IDC架構中的考慮。

第三個問題：這個是我在MySQL服務處理最多的效能Case，我見過有一些業務直接把錶拆成8192攻到一台機器上，也見過分割槽表建上上萬個分割槽，往往這些非常容易造成效能瓶頸。建議拆分時考慮演算法上支援二次拆分，不同一次拆的超過1000張表。

第四個問題：現在來看資料庫也從os database轉向了cloud native database 這裡面最大的特點，基本實現了資料透明拆分。如果在拆分方面還有痛苦，不如研究一下PolarDB, TiDB, TdSQL-C 這類產品。

我也希望：不遠的將來，這種分庫分表的方案，可能成為歷史。讓開發更爽一點。GL

3樓：普通熊貓

常見的程式優化方案並不多，其中「分」字輩的有：分幀、分頁、分批、讀寫分離、存算分離、分庫、分表。

然後呢，你會發現所有這些都是為了優化IO，要麼是減少IO次數，要麼是減少IO所涉及到的資料量，要麼是合併IO批次。

BTree索引也是為了優化IO，它通過特定的資料結構和演算法，使得程式可以基本上在1-2次IO的機會內迅速定位到資料。

但是，這要求BTree的第1-2層節點，甚至第3層節點都快取在記憶體中，也就是說要占用大量記憶體。錶太大的話，記憶體就裝不下索引了，然後就需要消耗磁碟IO讀取，就慢了。

還有乙個問題，事務模型是同步模型，也就是修改資料與修改索引必須是同時進行的。萬一修改了索引列的資料，BTree的資料結構就有可能發生比較大的調整。資料量越大，調整越慢。

其實，分庫分表還真不一定優先選擇，為此帶來的跨表join、跨庫事務、資料遷移都是非常討厭的改動。還有其他一些方向可以考慮呀，比如：移走舊的過期資料，公升級硬體配置。

都是不需要大動干戈，且切實有效的方案。

最近ocean base不是開源了嘛？講真，這才是未來，雖然現在誰都不想當出頭鳥。

4樓：一路向北

首先要明白，b+tree他的層級越少，那麼他的io次數就越少，即效率就越高

B+樹的乙個節點對應乙個資料頁, 查詢時, 從根節點到葉節點, 每讀取乙個資料頁到記憶體,IO次數+1. B+樹的層越高, 那麼要讀取到記憶體的資料頁也就越多, IO次數也就隨之增加. 分表的作用, 也就是為了避免資料量過多,導致樹的層變高, 而增加IO次數.

機器和資料庫也是有限的，資料量過大必定會使得效能有所下降，分庫可以將壓力相對均勻的分配在不同資料庫上，從而可以提公升效能

分表分割槽也類似，目的很明確就是盡量縮小查詢範圍，提公升效能