面試官：MySQL主鍵為什么不是連續遞增的？
設計MySQL表時，我們一般會設置一個自增主鍵，從而讓主鍵索引盡可能的保持遞增的趨勢，這樣可以避免頁分裂，讓MySQL順序寫入，大大提高MySQL的性能。
但是，自增主鍵只能保持大致遞增，無法保證順序遞增。
當我們創建完一個表后，通過show create table命令，可以看到MySQL定義了AUTO_INCREMENT來指定主鍵的遞增值。
在MySQL5.7之前，這個遞增值是直接保存在內存里面的，當服務器重啟后，MySQL會讀取表里面的最大主鍵id，然后將最大值+1作為下次遞增的值。
在MySQL8.0時，將其優化為了保存在redo log中，從而實現了遞增值的持久化。
那都有哪些情況可能導致主鍵不能連續遞增呢？
首先我們要知道的是，MySQL對于主鍵遞增值得使用是一次性的，即每次獲取完遞增值之后，不管接下來的語句是否能真正執行成功，這個遞增值都不會再回收利用了。
1、唯一索引沖突導致的主鍵不連續
有時為了滿足業務的需要，我們有時會對表中的字段設置唯一索引。但是當唯一索引沖突時，會產生什么問題呢？
以上面的user表為例，我們對name設置唯一索引。
我們執行兩次以下語句：
不難猜到，第二次的執行結果肯定會報錯：
我們在上面已經提到，MySQL對于遞增值的使用是一次性的，那么第二次執行插入時，不管語句成功還是失敗，那么這個遞增值就會浪費掉。
這時，我們再執行一條正常的不沖突的插入語句，會發現主鍵id產生了間隔。
2、事務回滾會造成主鍵不連續
與唯一索引沖突類似，當我們在一個事務中執行插入語句時，那么必然會向MySQL申請一個遞增值作為主鍵id，如果最后事務沒有提交，而是回滾，那么這個遞增值自然也就浪費掉了。
3、批量插入會造成主鍵不連續
為了保證主鍵id的唯一性，在申請自增id時，MySQL會對申請操作加鎖。一般情況下，這個申請動作會很快。
對于一般的批量插入，比如insert into ... values(xxx)，由于插入的Value個數可以提前計算得出，MySQL會一次性的申請足夠數量的id，以保證性能。
但是對于insert into ... select 這種語句就有點麻煩了，由于無法確定到底需要申請多個主鍵id，如果插入一條申請一個的話，假設要插入100萬條記錄，那就得申請100萬次，可想而知性能會有多么差勁。
所以對于這種批量插入的語句，MySQL采用了一種翻倍申請的優化策略：
語句執行時，第一次申請一個自增id，第二次申請2個自增id，第三次申請4個自增id...
即每次申請的數量都比上次多一倍，這樣雖然會浪費一些自增id，但是可以保證插入的效率，從性能角度來看，是可以接受的。
自增id為什么不回退復用
大家可能會有點疑問，為什么自增id是一次性使用的？
其實原因也很簡單，大家稍微一想就明白了。
假設有兩個事務在同時執行，為了保證自增id的唯一性，MySQL會對申請動作加鎖，然后兩個事務各獲得一個自增id。比如事務1申請到了自增id100，事務2申請到了自增id101。
當事務2成功提交，事務1因為某些原因回滾了。
如果我們要回退復用事務1的id，將AUTO_INCREMENT又設置成了100+1，那么下一個事務來申請自增id時，就會拿到101，而這時101已經被事務2用掉了，就會造成主鍵沖突。
當然我們也可以每次都讓MySQL檢查一下主鍵是否沖突，如果沖突就跳過這個id，但是這樣一來，本來申請自增id這個很輕的動作就會變得很重，對性能的影響就會很大。
所以，從性能角度考慮，InnoDB只保證了主鍵id是大致遞增的，而不保證是順序遞增的。?
