事务回滚后AUTO_INCREMENT值不还原是InnoDB的确定性行为，因自增ID在语句解析初期即预分配，早于事务判断，为避免高并发下性能损耗而设计。
为什么事务回滚后AUTO_INCREMENT值不还原
回滚操作不会让自增值倒退，这是InnoDB的确定性行为，不是bug。执行 BEGIN; INSERT INTO t VALUES (NULL, 1, 1); ROLLBACK; 后，SHOW CREATE TABLE t 显示的 AUTO_INCREMENT 值已+1，且无法撤销。
原因在于：自增ID在语句解析初期就完成预分配，早于实际写入和事务判断。若允许回退，高并发下需加更重锁或做唯一性校验，性能代价远高于“跳号”。
- 该行为与
innodb_autoinc_lock_mode无关，只要插入时未显式指定主键（即用NULL或省略），就会触发 - 不能靠
ALTER TABLE ... AUTO_INCREMENT = N回拨——若N小于当前最大id，MySQL 8.0+ 仅发 warning，5.7 及更早版本静默忽略 - 业务逻辑若依赖“连续递增”，必须重构；否则迟早遇到主键冲突或分页错乱
批量插入（INSERT SELECT / LOAD DATA）为何跳号严重
默认 innodb_autoinc_lock_mode = 1 下，INSERT INTO t SELECT ... 会一次性预申请多段ID，实际只用其中一部分，剩余被丢弃。例如表当前 AUTO_INCREMENT = 100，插入5行可能直接升到108。
这不是配置错误，而是InnoDB为减少锁竞争做的并发优化。设为 2（交错模式）可缓解但不消除，且要求 binlog_format = ROW；设为 0（传统全表锁）能保证连续，但吞吐暴跌，线上禁用。
- 查当前模式：
SELECT @@innodb_autoinc_lock_mode; - 动态改模式：
SET GLOBAL innodb_autoinc_lock_mode = 1;（注意主从一致性，GTID复制下需同步修改） - 真正要控制ID节奏，只能放弃批量语句，改用单条
INSERT循环，或由应用层生成主键（如雪花ID）
唯一键冲突也会消耗自增ID
建表含 UNIQUE KEY c(c)，已有 (1, 1, 1)，再执行 INSERT INTO t VALUES (NULL, 1, 2) 报 Duplicate entry '1' for key 'c'，但 AUTO_INCREMENT 已升至2——ID在冲突判定前就分配了。
这个流程固定：引擎先取当前自增值 → 改写SQL中的 NULL → 再校验唯一约束 → 失败后丢弃整行，但ID不回收。
- 哪怕表里只有1行，反复触发唯一冲突，
AUTO_INCREMENT也会一路涨上去 - 无法通过任何SQL清理“已分配未使用”的ID段
- 若业务频繁出现这类冲突（如幂等插入），建议改用
INSERT IGNORE或ON DUPLICATE KEY UPDATE，至少避免无谓的ID浪费
MySQL重启后AUTO_INCREMENT变小是怎么回事
这在MySQL 5.7及更早版本是常态：自增值只存内存，重启后InnoDB扫描表数据，取 MAX(id) + 1 作为新起点。删光数据后重启，AUTO_INCREMENT 可能从100掉回1。
MySQL 8.0起通过redo log持久化自增值，重启不再丢失。若仍在用5.7，别信“INSERT + DELETE锚定高位值”这种野路子——它治标不治本，且可能引发主从延迟或死锁。
- 确认版本：
SELECT VERSION(); - 查当前最大ID：
SELECT MAX(id) FROM your_table; - 查当前AUTO_INCREMENT值：
SHOW CREATE TABLE your_table;（对比二者，若前者 ≥ 后者，说明值已被覆盖） - 长期方案只有升级，没有安全又可靠的“修复”手段
