原文：https://www.jianshu.com/p/6815674eacad/
------------------
相信有不少人在面試的時候都會碰到這樣的場景！
面試官:"用過MySQL吧，你們是用自增主鍵還是UUID？"
你:"用的是自增主鍵。"
面試官:"為什么不用UUID，而用自增主鍵？"
你:"因為采用自增主鍵，數據在物理結構上是順序存儲，性能最好....."
面試官:"那自增鍵的最大值是多少？自增鍵達到最大值了，用完了，你怎么辦"
你:"what，自增鍵的值能用完？"
恰好我學弟在面試時也遇到了。我覺得挺有意思的，所以就這個問題。來談談“這個自增主鍵用完了該怎么辦！”
首先我們要清楚一點，在MySQL中Int整型的范圍如下：
以無符號整型為例，其最大值為：4294967295。大哥，這是約為43億啊！正常情況下，單表是不可能達到這個值的啊！當然如果頻繁的刪除或者頻繁消耗自增列的值，單表到達42億也是日可待。
一旦自增id達到最大值，此時數據繼續插入是會報一個主鍵沖突異常如下所示：
//Duplicate entry '4294967295' for key 'PRIMARY'
這時，解決方法也很簡單，只需要把 Int 改為 BigInt 。BigInt的范圍如下：
其最大值：18446744073709551615，好吧！我已經不知道怎么讀了。具體用完時間，如下所示：
因此，將 Int 改成 BigInt。你根本不用考慮自增長值會達到最大值越界問題。
當然了。在實際的項目中，我們也不可能這么干。因為數據到達一定的量以后。你每次查詢所花費的時間越長，如果還有聯合查詢的話。不說是億量級的數據，就算只有幾千萬，幾百萬。那程序都有可能死在那兒。
這個時候你就要考慮分庫分表了。一旦分庫分表了，就不能依賴於每個表的自增ID來全局唯一標識這些數據了。此時，我們就需要提供一 個全局唯一的ID號生成策略來支持分庫分表的環境。同時分庫分表 還可以減小數據庫的負擔，縮短查詢時間。
具體的分庫分表策略，你需要關注 【不正經的碼農】 回復 【mycat】即可領取教程資料。
回到面試官的問題：“那自增主鍵達到最大值了，用完了怎么辦？”；
專業點回答：
"這問題沒遇到過，因為自增主鍵一般用int類型，一般達不到最大值，我們就分庫分表了，所以不曾遇見過！"
想學習MySQL 的小伙伴們 可關注【不正經的碼農】回復【mysql】即可免費領取視頻教程+ 課程筆記。
作者：逝唚
鏈接：https://www.jianshu.com/p/6815674eacad/
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。