MySQL單表數據不要超過500萬行：是經驗數值，仍是黃金鐵律？

原文地址：梁桂釗的博客

博客地址：blog.720ui.com

歡迎關注公衆號：「服務端思惟」。一羣同頻者，一塊兒成長，一塊兒精進，打破認知的侷限性。

今天，探討一個有趣的話題：MySQL 單表數據達到多少時才須要考慮分庫分表？有人說 2000 萬行，也有人說 500 萬行。那麼，你以爲這個數值多少才合適呢？

曾經在中國互聯網技術圈廣爲流傳着這麼一個說法：MySQL 單表數據量大於 2000 萬行，性能會明顯降低。事實上，這個傳聞聽說最先起源於百度。具體狀況大概是這樣的，當年的 DBA 測試 MySQL性能時發現，當單表的量在 2000 萬行量級的時候，SQL 操做的性能急劇降低，所以，結論由此而來。而後又聽說百度的工程師流動到業界的其它公司，也帶去了這個信息，因此，就在業界流傳開這麼一個說法。

再後來，阿里巴巴《Java 開發手冊》提出單錶行數超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。對此，有阿里的黃金鐵律支撐，因此，不少人設計大數據存儲時，多會以此爲標準，進行分表操做。

那麼，你以爲這個數值多少才合適呢？爲何不是 300 萬行，或者是 800 萬行，而是 500 萬行？也許你會說這個可能就是阿里的最佳實戰的數值吧？那麼，問題又來了，這個數值是如何評估出來的呢？稍等片刻，請你小小思考一下子。

事實上，這個數值和實際記錄的條數無關，而與 MySQL 的配置以及機器的硬件有關。由於，MySQL 爲了提升性能，會將表的索引裝載到內存中。InnoDB buffer size 足夠的狀況下，其能完成全加載進內存，查詢不會有問題。可是，當單表數據庫到達某個量級的上限時，致使內存沒法存儲其索引，使得以後的 SQL 查詢會產生磁盤 IO，從而致使性能降低。固然，這個還有具體的表結構的設計有關，最終致使的問題都是內存限制。這裏，增長硬件配置，可能會帶來立竿見影的性能提高哈。

那麼，我對於分庫分表的觀點是，須要結合實際需求，不宜過分設計，在項目一開始不採用分庫與分表設計，而是隨着業務的增加，在沒法繼續優化的狀況下，再考慮分庫與分表提升系統的性能。對此，阿里巴巴《Java 開發手冊》補充到：若是預計三年後的數據量根本達不到這個級別，請不要在建立表時就分庫分表。那麼，回到一開始的問題，你以爲這個數值多少才合適呢？個人建議是，根據自身的機器的狀況綜合評估，若是內心沒有標準，那麼暫時以 500 萬行做爲一個統一的標準，相對而言算是一個比較折中的數值。

寫在末尾

【服務端思惟】：咱們一塊兒聊聊服務端核心技術，探討一線互聯網的項目架構與實戰經驗。讓全部孤軍奮戰的研發人員都找到屬於本身的圈子，一塊兒交流、探討。在這裏，咱們能夠認知升級，鏈接頂級的技術大牛，鏈接優秀的思惟方式，鏈接解決問題的最短路徑，鏈接一切優秀的方法，打破認知的侷限。

更多精彩文章，盡在「服務端思惟」！