1. 程式人生 > >MySQL單表最大記錄數不能超過多少?

MySQL單表最大記錄數不能超過多少?

MySQL單表最大記錄數不能超過多少?

很多人困惑這個問題。其實,MySQL本身並沒有對單表最大記錄數進行限制,這個數值取決於你的作業系統對單個檔案的限制本身。

從效能角度來講,MySQL單表資料不要超過多少呢?業界流傳是500萬行。超過500萬行就要考慮分表分庫了。

筆者以為,其實不然。

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

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

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

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

那麼,我對於分庫分表的觀點是,需要結合實際需求,不宜過度設計,在專案一開始不採用分庫與分表設計,而是隨著業務的增長,在無法繼續優化的情況下,再考慮分庫與分表提高系統的效能。

對此,阿里巴巴《Java 開發手冊》補充到:如果預計三年後的資料量根本達不到這個級別,請不要在建立表時就分庫分表。那麼,回到一開始的問題,你覺得這個數值多少才合適呢?我的建議是,根據自身的機器的情況綜合評估,如果心裡沒有標準,那麼暫時以 500 萬行作為一個統一的標準,相對而言算是一個比較折中的數值。

原文轉載自:https://mp.apipost.cn/a/34e44b63c6a6