前幾天有個朋友出去面試，被面試官問到MySQL自增主鍵id用完了怎么辦？由于對這塊了解不多，所以回答得不太理想。
本篇文章為大家分享一下，MySQL自增主鍵達到上限以后會發生什么情況？該如何解決這種情況？
我們在定義MySQL表時，為了性能考慮，一般會使用MySQL的自增主鍵id，每個自增id都會定義一個初始值，一般從1開始，然后不停得增加步長（不配置的話步長默認為1）。
但是不知道大家考慮過沒有，我們定義的int或者bigint都是有長度上限的。
如果表中的最大記錄id超過這個上限值，MySQL會發生什么錯誤呢？
從上圖可以看出，tinyint和smallint的范圍都比較小，我們一般不會將其作為主鍵id的類型。
如果主鍵采用有符號int類型進行自增，那么id的最大值是2147483647，如果采用無符號int類型進行自增，那么id的最大值是4294967295。
以無符號int類型為例，42億雖然看起來是個很大的數字，但是對于一些插入刪除很頻繁的業務來說，并非無法觸達這個上限。
特別是有的業務表設置的步長比較大，會導致id自增的速度更快。
首先，我們來驗證一下，當MySQL的自增主鍵達到最大值后，再往表中插入數據會出現什么現象？
新建一張表，并且直接指定最大自增值為4294967295。
CREATE TABLE t_max( id int unsigned auto_increment PRIMARY KEY ) auto_increment = 4294967295;
執行幾次以下sql看看會出現什么結果。
INSERT t_max ( id ) VALUES ( NULL );
可以看到，直接提示主鍵重復了。
這里我們也可以驗證MySQL的主鍵策略：id自增值達到上限以后，再申請下一個 id 時，仍然是最大值。
所以，如果你的業務預期會產生很多數據，那么建議你在創建表時，直接使用bigint，無符號的bigint最大值是18446744073709551615，這個數基本可以保證你的業務不受影響了。
當然，如果主鍵需要對外展示，為了安全考慮，大家也可以采用雪花算法生成的主鍵值，雪花算法產生的值和bigint一樣都占用8個字節，并且是大致遞增的，對性能也不會產生影響。
另外多說幾句，建表時采用什么類型的主鍵，還是要根據具體業務具體分析，合理的主鍵類型會占用更小的空間，具有更好的性能。畢竟bigint占用8個字節，比int多了一倍呢。
