看到這個問題，我想起當初玩魔獸世界的時候，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');
然後查詢資料會發現3條資料是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 -