自增值

1.innodb_autoinc_lock_mode 

自增列的鎖狀態，有三種選值： 0 1 2

innodb_autoinc_lock_mode =0
所有的isert 都會持有AUTO-INC table-level lock直到語句結束，statement-based 這種複製模式下，從庫的自增列值會和主庫保持一致。


innodb_autoinc_lock_mode =1
這種模式為預設模式，可以預估需要插入多少行，分配多少個自增值得簡單插入會避免使用AUTO-INC table-level lock。 INSERT ... SELECT,  REPLACE ... SELECT, and  LOAD DATA對於這種複雜insert還是會選擇持有AUTO-INC table-level lock直到語句結束，這種情況下，如果既有簡單插入又有行數不確定的出入一起執行的時候，innndb一般會分配比要求的行數更多的自增列值，但是分配的值還是會保證連續，多分配的值則會丟失。


innodb_autoinc_lock_mode =2
這種模式允許併發，可擴充套件性,不會持有table-level  AUTO-INC lock





2.自增值在MySQL8.0有一個較大的改變，以前的自增值會在重啟之後取max(primary_id)+1,這種情況某些情況會導致主鍵衝突或者其他問題。

相關bug：

相關bug解決： https://dev.mysql.com/worklog/task/?id=6204

However, the same has already been fixed in 8.0 by WL#6204 - InnoDB persistent max value for autoinc columns.
Upgrading to 8.0 will fix the issue.

具體的改進為：

1. The AUTOINC counters would get persisted through redo logs
透過redo log持久化
2. All AUTOINC counters would be collected from redo logs and applied to
in-memory counters if they're bigger.
所有的自增值將會記入redo log 並且會在很大的時候應用到記憶體中的計數器
3. There won't be any rollback of AUTOINC counters.
他們不會被rollback
4. 'SELECT MAX(c) FROM t' would not be needed except when IMPORT tablespace.
SELECT MAX(c) FROM t'除了在表空間匯入的時候，其他時候都不需要了
5. The largest updated counter will be logged and will not change with reboot.
最大的更新計數器不會在重啟的時候改變
6. Considering performance, we could write some extra redo logs, but no
new MTRs.
對於效能來說，會有一些額外的redo log寫入，但是沒有新的MTRs

3.另外還有一個改變點就是replace into的bug，replace的時候如果唯一鍵值存在，則會記錄為delete+insert，影響行數是2，但是binlog的記錄是update操作，這樣從庫同步僅執行了update，不會更新自增值。

In MySQL 8.0, updating an existing AUTO_INCREMENT column value in an InnoDB table
also resets the AUTO_INCREMENT sequence.