看到這個問題，我想起當初玩魔獸世界的時候，25H難度的腦殘吼的血量已經超過了21億，所以那時候副本的BOSS都設計成了轉階段、回血的模式，因爲魔獸的血量是int型，不能超過2^32大小。
估計暴雪的設計師都沒想到幾個資料片下來血量都超過int上限了，以至於大家猜想纔會有後來的屬性壓縮。
這些都是題外話，只是告訴你數據量大了是有可能達到上限的而已，回到Mysql自增ID上限的問題，可以分爲兩個方面來說。
1.有主鍵
如果設置了主鍵，並且一般會把主鍵設置成自增。
我們知道，Mysql裏int類型是4個字節，如果有符號位的話就是[-2^31,2^31-1]，無符號位的話最大值就是2^32-1，也就是4294967295。
創建一張表試試：
CREATE TABLE `test1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(32) NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2147483647 DEFAULT CHARSET=utf8mb4;
然後執行插入
insert into test1(name) values('qq');
這樣表裏就有一條達到有符號位的最大值上限的數據。
如果再次執行插入語句：
insert into test1(name) values('ww');
就會看到錯誤提示：1062 - Duplicate entry '2147483647' for key 'PRIMARY', Time: 0.000000s。
也就是說，如果設置了主鍵並且自增的話，達到自增主鍵上限就會報錯重複的主鍵key。
解決方案，mysql主鍵改爲bigint，也就是8個字節。
設計的時候要考慮清楚值的上限是多少，如果業務頻繁插入的話，21億的數字其實還是有可能達到的。
2.沒有主鍵
如果沒有設置主鍵的話，InnoDB則會自動幫你創建一個6個字節的row_id，由於row_id是無符號的，所以最大長度是2^48-1。
同樣創建一張表作爲測試：
CREATE TABLE `test2` (
`name` varchar(32) NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
通過ps -ef|grep mysql拿到mysql的進程ID，然後執行命令，通過gdb先把row_id修改爲1
sudo gdb -p 2584 -ex 'p dict_sys->row_id=1' -batch
然後插入幾條數據：
insert into test2(name) values('1');
insert into test2(name) values('2');
insert into test2(name) values('3');
再次修改row_id爲2^48，也就是281474976710656
sudo gdb -p 2584 -ex 'p dict_sys->row_id=281474976710656' -batch
再次插入數據
insert into test2(name) values('4');
insert into test2(name) values('5');
insert into test2(name) values('6');
然後查詢數據會發現4條數據，分別是4，5，6，3。
因爲我們先設置row_id=1開始，所以1，2，3的row_id也是1，2，3。
修改row_id爲上限值之後，row_id會從0重新開始計算，所以4，5，6的row_id就是0，1，2。
由於1，2數據已經存在，數據則是會被覆蓋。
總結
自增ID達到上限用完了之後，分爲兩種情況：
如果設置了主鍵，那麼將會報錯主鍵衝突。
如果沒有設置主鍵，數據庫則會幫我們自動生成一個全局的row_id，新數據會覆蓋老數據
解決方案：
表儘可能都要設置主鍵，主鍵儘量使用bigint類型，21億的上限還是有可能達到的，比如魔獸，雖然說row_id上限高達281萬億，但是覆蓋數據顯然是不可接受的。
—————END—————
喜歡本文的朋友，歡迎關注公衆號 程序員小灰，收看更多精彩內容
點個[在看]，是對小灰最大的支持！