以前沒有想過MySQL數據庫的單表最大行數，直到最近interview時被問到c語言中int類型的最大值是多少時才想到Mysql單表最大行數的問題。

一開始被問到C語言中int類型的最大值有點懵逼，一般這種問題都是在校招時候會被問到，對于工作多年的人不會問這個問題。被問到這個問題的時候，大腦中思考的不是int類型最大值到底是多少？而是為什么這個問題很經典，經常被問，了解這個東西能用到什么地方呢？于是很快想到了MySql單表的最大記錄數是多少，因為表的id一般是自增長的int類型。

---

MySQL單表最大記錄數超過多少時性能會嚴重下降？

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

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

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

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

那么，我對于分庫分表的觀點是，需要結合實際需求，不宜過度設計，在項目一開始不采用分庫與分表設計，而是隨著業務的增長，在無法繼續優化的情況下，再考慮分庫與分表提高系統的性能。

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

---

mysql bigint auto_increment 自增長值的最大數量

bigint
有符號值：-9223372036854775808 到9223373036854775807（- 2 ^ 63 到 2 ^ 63-1）
無符號值：0到18446744073709551615（0到2^64 – 1）

創建表時 自增長字段 選擇無符號bigint，那么自增長最大值是 18446744073709551615

一秒增加的記錄條數?? ?大約多少年后才會用完

一秒增加的記錄條數	大約多少年后才會用完
1/秒	584942417355 年
1萬/秒	58494241 年
100萬/秒	584942 年
1億/秒	5849年

?

?

?

?

?

參考文章：

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

mysql bigint auto_increment 自增長值超過最大數量之后插入失敗的問題

總結

以上是生活随笔為你收集整理的数据库性能优化—MySQL单表最大记录数超过多少时性能会严重下降的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。