既然這塊知識點不清楚，那回頭就自己動手實踐下。
首先，創建一個最簡單的表，只包含一個自增id，并插入一條數據：
———————
create table t0(id int unsigned auto_increment primary key) ;
insert into t0 values(null);
————————————————▲
通過show命令show create table t0;查看表情況：
———————
CREATE TABLE `t0` (
? `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
? PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8
————————————————▲
可以發現 AUTO_INCREMENT 已經自動變成2，這離用完還有很遠，我們可以算下最大當前聲明的自增ID最大是多少，由于這里定義的是intunsigned，所以最大可以達到2的32冪次方 - 1 = 4294967295
這里有個小技巧，可以在創建表的時候，直接聲明AUTO_INCREMENT的初始值：
———————
create table t1(id int unsigned auto_increment primary key)? auto_increment = 4294967295;
insert into t1 values(null);
————————————————▲
同樣，通過show命令，查看t1的表結構：
———————
CREATE TABLE `t1` (
? `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
? PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4294967295 DEFAULT CHARSET=utf8
————————————————▲
可以發現，AUTO_INCREMENT已經變成4294967295了，當想再嘗試插入一條數據時，得到了下面的異常結果：
17:28:03? ? insert into t1 values(null) Error Code: 1062. Duplicate entry '4294967295' for key 'PRIMARY'? ? 0.00054 sec
說明，當再次插入時，使用的自增ID還是4294967295，報主鍵沖突的錯誤。
4294967295，這個數字已經可以應付大部分的場景了，如果你的服務會經常性的插入和刪除數據的話，還是存在用完的風險，建議采用bigint unsigned，這個數字就大了。
不過，還存在另一種情況，如果在創建表沒有顯示申明主鍵，會怎么辦？
如果是這種情況，InnoDB會自動幫你創建一個不可見的、長度為6字節的row_id，而且InnoDB 維護了一個全局的 dictsys.row_id，所以未定義主鍵的表都共享該row_id，每次插入一條數據，都把全局row_id當成主鍵id，然后全局row_id加1
該全局row_id在代碼實現上使用的是bigint unsigned類型，但實際上只給row_id留了6字節，這種設計就會存在一個問題：如果全局row_id一直漲，一直漲，直到2的48冪次-1時，這個時候再+1，row_id的低48位都為0，結果在插入新一行數據時，拿到的row_id就為0，存在主鍵沖突的可能性。
所以，為了避免這種隱患，每個表都需要定一個主鍵。
“我是一名從事了10年開發在退休邊緣垂死掙扎的高齡程序員，最近我花了一些時間整理了一個完整的學習C語言、C++的路線，項目源碼和工具。對于想學習C/C++的小伙伴而言，學習的氛圍和志同道合的伙伴很重要，筆者推薦我專欄的C語言/C++編程愛好者的聚集地>>>C語言/C++進階之路 - 專題 - 簡書！
歡迎初學和進階中的小伙伴。希望你也能憑自己的努力，成為下一個優秀的程序員。工作需要、感興趣、為了入行、轉行需要學習C/C++的伙伴可以一起學習！”
喜歡小編的記得動動您的小指點個關注喲！
