原文位址： 梁桂钊的部落格 部落格位址： http://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 萬行作為一個統一的标準，相對而言算是一個比較折中的數值。
寫在末尾
【服務端思維】：我們一起聊聊服務端核心技術，探讨一線網際網路的項目架構與實戰經驗。讓所有孤軍奮戰的研發人員都找到屬于自己的圈子，一起交流、探讨。在這裡，我們可以認知更新，連接配接頂級的技術大牛，連接配接優秀的思維方式，連接配接解決問題的最短路徑，連接配接一切優秀的方法，打破認知的局限。
更多精彩文章，盡在「服務端思維」！