寫在前面

前幾天樑大發表了mysql單表500w資料分表的鐵律，也參與了回覆，結果同一天隔壁組面試，正好問了下面試者這個問題，面試官想在多方面考察面試者技術紮實程度，結果面試者回答的不好，所以整理一篇，決定分庫分表的原因有哪些？

單表資料量角度

這是樑大文章中闡述的主要原因之一：

曾經在中國網際網路技術圈廣為流傳著這麼一個說法：MySQL 單表資料量大於 2000 萬行，效能會明顯下降。事實上，這個傳聞據說最早起源於百度。具體情況大概是這樣的，當年的 DBA 測試 MySQL效能時發現，當單表的量在 2000 萬行量級的時候，SQL 操作的效能急劇下降，因此，結論由此而來。然後又據說百度的工程師流動到業界的其它公司，也帶去了這個資訊，所以，就在業界流傳開這麼一個說法。

阿里巴巴《Java 開發手冊》提出單錶行數超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。對此，有阿里的黃金鐵律支撐，所以，很多人設計大資料儲存時，多會以此為標準，進行分表操作。

事實上，這個數值和實際記錄的條數無關，而與 MySQL 的配置以及機器的硬體有關。因為，MySQL 為了提高效能，會將表的索引裝載到記憶體中。InnoDB buffer size 足夠的情況下，其能完成全載入進記憶體，查詢不會有問題。但是，當單表資料庫到達某個量級的上限時，導致記憶體無法儲存其索引，使得之後的 SQL 查詢會產生磁碟 IO，從而導致效能下降。當然，這個還有具體的表結構的設計有關，最終導致的問題都是記憶體限制。這裡，增加硬體配置，可能會帶來立竿見影的效能提升哈。

單行資料特點角度

這是飛哥的觀點，分庫分表原因和每行記錄大小有關係，因為b+ tree索引葉子節點儲存真實記錄資料，每條記錄大小決定了每個葉子節點能儲存多少記錄，影響了b+tree索引樹的高度，從而影響了效能。

業務特點角度

春哥大魔王的角度是從業務角度切入，比如虛擬機器mysql例項的寫qps瓶頸大概在3k左右，物理機mysql例項的寫qps瓶頸大概可以摸高到1w，但是隨著業務場景發展，隨便搞個大促，或者推廣，整個系統的瓶頸就會暴露出來，所以需要提早做分庫分表了。

連線數角度

另一個角度可以是連線數，因為隨著單個mysql例項連線的下游服務越來越多，導致mysql和服務之間建立大量的長連線，連線數量是完全有上限的，可以通過讀寫分離，分庫分表等多個角度降低連線數造成的效能問題。

最後

所以分庫分表，資料量只是其中的因素之一，可以從機器配置，mysql原理，連線池，業務特點等多個角度考慮。

相關推薦