決定分庫分表的緣由有哪些？

寫在前面

前幾天梁大發表了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原理，鏈接池，業務特色等多個角度考慮。