今天，探討一個有趣的主題：MySQL 單表資料達到多少時才需要考慮分庫分錶？有人說 2000 萬行，也有人說 500 萬行。那麼，你覺得這個數值多少才合適呢？
曾經在中國網路科技圈廣為流傳著這麼一個說法：MySQL 單表資料量大於 2,000 萬行，效能會明顯下降。事實上，這個傳聞據說最早起源於百度。具體情況大概是這樣的，當年的 DBA 測試 MySQL效能時發現，當單表的量在 2000 萬行量級的時候，SQL 操作的效能急劇下降，因此，結論由此而來。然後又據說百度的工程師流向業界的其它公司，也帶去了這個訊息，所以，就在業界流傳開這麼一個說法。
再後來，阿里巴巴《Java 開發手冊》提出單表行數超過 500 萬行或單表容量超過 2GB，才建議進行分庫分錶。對此，有阿里的黃金鐵律支撐，所以，很多人設計大數據儲存時，多會以此為標準，進行分錶操作。
那麼，你覺得這個數值多少才合適呢？為什麼不是 300 萬行，或是 800 萬行，而是 500 萬行？也許你會說這個可能就是阿里的最佳實戰的數值吧？那麼，問題又來了，這個數值是如何被評估出來的呢？稍等片刻，請你小小思考一會兒。
事實上，這個數值和實際記錄的條數無關，而是與 MySQL 的配置以及機器的硬體有關。因為，MySQL 為了提高效能，會將表的索引載入到記憶體中。 InnoDB buffer size 足夠的情況下，其能完成全加載進內存，查詢不會有問題。但是，當單一表格資料庫到達某個量級的上限時，導致記憶體無法儲存其索引，使得之後的 SQL 查詢會產生磁碟 IO，從而導致效能下降。當然，這個還有具體的表結構的設計有關，最終導致的問題都是記憶體限制。這裡，增加硬體配置，可能會帶來即時的效能提升哈。
那麼，我對於分庫分錶的觀點是，需要結合實際需求，不宜過度設計，在專案一開始不採用分庫與分錶設計，而是隨著業務的增長，在無法在繼續優化的情況下，再考慮分庫與分錶提高系統的效能。對此，阿里巴巴《Java 開發手冊》補充到：如果預計三年後的資料量根本達不到這個級別，請不要在創建表時就分庫分錶。那麼，回到一開始的問題，你覺得這個數值多少才適合呢？我的建議是，根據自身的機器的情況綜合評估，如果心裡沒有標準，那麼暫時以 500 萬行作為一個統一的標準，相對而言算是一個比較折中的數值。
更多MySQL相關技術文章，請造訪MySQL教學欄位進行學習！
以上是MySQL單表資料不要超過500萬行：是經驗數值，還是黃金鐵律？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
