原文：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】即可免費領取視訊教程+ 課程筆記。