1.情景展示
在實際開發中，往往會存在這種需求：
將A表當中的數據導入B表，后面繼續使用B表。
由上一篇，我們了解到：
B表如果是通過create table b as select * from a的方式，將會導致的其中一個結果就是：
B表沒有指定主鍵列。
2.具體分析
現在的問題在於：
假如，我們現在還將ID列作為主鍵，並且設置成自增列的話，該ID的起始值將是多少？
一起來實際操作一下吧：
第一步：將ID列設置成主鍵；
第二步：取消勾選“自動遞增”；
第三步：將主鍵列的默認值清空。
點擊保存。
使用建表語句，看一下序列的起始值；
序列的起始值為：9；
我們再來運行一下建表語句：
show CREATE TABLE cz_jkdic_bak;添加主鍵前：
添加主鍵后：
\
我們可以看到：
建表語句，除了增加了主鍵列外，還設置了自增的起始值：AUTO_INCREMENT=9。
我們來看一下當前主鍵列的最大值：
最大值為8，這，也就是說：mysql會自動將現有主鍵列的最大值+1，當作自增的起始值；
這一點還是非常不錯的，這樣一來，我們就無需擔心主鍵沖突的問題，也不用手動去改主鍵序列的起始值啦。
3.解決方案
如何修改主鍵起始值？
錯誤方式一：修改AUTO_INCREMENT；
語法：
ALTER TABLE 表名 AUTO_INCREMENT=起始值
顯示執行成功，我們再可以查看一下建表語句；
2022年5月23日19:24:32
雖然，建表語句的自增長起始值發生了改變，但是，然並卵。
我們在插入數據的時候，主鍵依然按照原來的值的基礎上+1（8+1）。
在mysql客戶端當中，有一個bug會讓我們這樣的錯覺：
誤以為，這種方式值有效的。
誠然，在Navicat當中，進行新增的時候，是生效的。
但是，我們切換到對象，可以看到該表的自增值。
我們可以清楚的看到：
該表主鍵列的自增值並未發生改變。
而且，我們操作數據，一般是通過程序操作，而不是直接操作數據庫。
同樣地，在SQLYog當中，我們再試一次：
選中表，右鍵，改變表；
查看表主鍵。
我們可以看到：表主鍵的自增值，依舊沒有改變。
結論：通過這種實現方式，只對當前客戶端有效，並未修改表的主鍵值，無論是相較與當前數據主鍵的最大值，將主鍵值調大或者調小。
當自增值為NULL或0的時候，這種方式會起作用。
錯誤方式二：SQLyog工具。
鼠標選中要修改的表，快捷鍵：F6；
自動增量，這一欄就是序列的下一個值；
修改之后，保存。
雖然顯示：已經修改成功，但是，我們會發現：自增值並未發生改變。
2022年5月23日19:59:07
mysql主鍵特性：
mysql的自增列，有以下特性：
每次增加的值為1；
在取自增值時，會先去查當前主鍵的最大值，然后和當前自增值進行比對：
如果，自增值>現有數據主鍵的最大值，則取自增值，作為新數據的主鍵；
反之，自增值<=現有數據主鍵的最大值，則取現有數據主鍵的最大值+1，作為新數據的主鍵。
mysql的自增列的值，一般情況下，只會越來越大，是無法人為手動變小的。
正確實現方式：
第一步：復制表；
CREATE TABLE meta_theme_bak as SELECT * FROM meta_theme我們可以看到：
此時，備份表的自增列的值為0。
注意：使用這種復制表的方式，會導致主鍵、索引等相關信息的丟失。
第二步：刪除舊表；
DROP TABLE meta_theme
第三步：對備份表進行重命名；
第四步：重新設置表主鍵、索引、表名注釋等相關信息。
添加主鍵，並勾選“自動遞增”，保存。
隨后，我們可以看到，表的主鍵自增值已經改成了在原有數據最大值的基礎上+1。
還有一種實現方式：清空表數據
表數據被清空后，我們依然可以發現：
表的自增值並未發生任何變化。
select
auto_increment
from
information_schema.`tables`
where
table_name = '表名'
and table_schema = '數據庫名'
但是，我們在實際插入數據的時候，表主鍵已經從1重新開始了。
由此可見，表的AUTO_INCREMENT並不可信，只有在實際插入的時候，我們才知道主鍵會是多少！
寫在最后
哪位大佬如若發現文章存在紕漏之處或需要補充更多內容，歡迎留言！！！