例：
table t ;
insert into t values(null,1)
自增值的儲存策略
myisam:
儲存於資料檔案中。
innodb:
mysql5.7及以前會儲存於記憶體中，每次重啟開啟會去找自增列的最大值，然後將這個值+1作為當前自增值。
重啟會修改表的自增值，例：
假設當前表自增列最大值為10，自增值為11。刪除自增列為10的之後重啟，此時自增列最大值為9，自增值變為10。
mysql8.0+會將自增值儲存在redo log中，重啟不會變化。
自增值機制
1.如果插入資料的自增字段為0、null或者未指定，就將表當前自增值填入。
2.如果插入資料的自增字段有指定值x，會直接使用當前x插入，表自增值y也會根據x而改變：
2.1 如果x＜y，那麼表的自增值為y。
2.2 如果x ≥ y，就需要從auto_increment_offset以auto_increment_increment為步長，找到第乙個大於x的值作為新的自增值。
執行流程：
執行器呼叫innodb引擎寫入插入行。
執行插入操作，成功/報錯。
批量申請自增值：
對於批量插入，mysql有乙個批量申請自增字段的策略：
1.語句執行過程中，第一次申請自增字段會分配乙個自增值。
2.第二次申請會分配兩個。
3.以此類推，同乙個語句去多次申請自增值，每次申請到的數量是上一次的兩倍。
自增不連續
唯一鍵衝突
未指定自增字段資料，插入時產生了唯一鍵衝突，由於自增值修改優先執行於插入操作，自增值已修改但插入報錯。
插入回滾
未指定自增字段資料，在插入事務中進行回滾，自增值已修改但未插入。
批量申請造成的自增浪費
未指定自增字段的多條資料，在同一語句內去申請填充自增字段，若申請的自增欄位多於資料數量，那麼將會出現自增字段浪費的情況。
自增不回退
自增回退：
併發執行時如果進行自增回退可能會造成鍵值衝突。（自增字段必須是唯一）
例如兩個並行執行事務操作同一張表，事務a申請到自增值為2，事務b申請到自增值為3，此時表自增值為4。假設b提交成功但是a提交失敗且允許自增值回退，那麼回退後的表自增值為2。後續再次執行時申請自增值會申請到為3的值，就會產生唯一衝突。
解決方法：
每次申請之前先去判斷是否存在，存在就跳過。
自增值得鎖範圍擴大至事務執行提交後，這樣在事務完成後下個事務才可申請自增值。
問題：由於解決方法影響效能，所以innodb不支援自增回退。
自增鎖優化
在mysql 5.1.22新增了innodb_autoinc_lock_mode引數，預設值為1。
為0時，採用mysql5.0之前的策略，即語句執行結束後才釋放鎖。
為1時：
2.1 insert語句，自增鎖在申請之後就釋放。
2.2 類似insert…select這類的批量插入資料，自增鎖要等語句結束才釋放。
為2時，所有鎖都是申請後就釋放。
關於2.2的說明：
假設自增值申請結束立馬釋放自增鎖，那麼t2資料有可能為（1，1，1），（2，2，2），（4，3，3），（5，4，4），（3，5，5）。
假設binlog_format=statement，那麼從庫執行binlog時就可能會產生資料不一致。
解決辦法：
1.原庫批量插入時，固定生成連續id，自增鎖知道語句執行結束才釋放。
2.在binlog中把插入資料如實記錄。設定innodb_autoinc_lock_mode為2，binlog_format為row。
相比於1，2提公升併發效能問題解決了資料不一致的問題。
mysql實戰45講學習筆記 02
2.日誌系統 一條sql更新語句是如何執行的 一條查詢語句執行過程是經過聯結器，分析器，優化器，執行器等功能模組最後到達儲存引擎 查詢語句的流程，更新語句也是會同樣走一遍。更新流程還涉及兩個重要的日誌系統，redo log 重做日誌 和binlog 歸檔日誌 重要的日誌模組 redo log mys...
mysql實戰45講學習筆記 11
11 怎麼給字串欄位加索引字首索引的優勢，選取欄位前幾個作為索引，占用的空間更小 使用字首索引，定義好長度，就可以做到既節省空間，又不用額外增加太多的查詢成本。建立索引的時候關注的是區分度，區分度越高越好，區分度越高，意味著重複的鍵值越少，因此，可以通過統計索引上有多少不同的值來判斷使用多長字首。m...
mysql實戰45講學習筆記 12
為什麼我的mysql 抖 了一下一條sql語句，正常執行的時候特別快，但有時會突然變得特別慢，並且隨機，持續時間短。將對應的記憶體資料寫入到磁碟的過程，叫做flush。當記憶體資料頁跟磁碟資料頁內容不一致的時候，我們稱這個記憶體頁為 髒頁 記憶體資料寫入到磁碟後，記憶體和磁碟上的資料頁就一致，稱為 ...