mysql 8.0重启后auto_increment不回溯，根本原因是自增值变更被写入redo log并参与崩溃恢复：启动时重放redo日志获取最新已分配值，再与表中max(id)比较取较大者加步长；该机制仅适用于innodb，且不解决id不连续问题。
MySQL 8.0重启后AUTO_INCREMENT不回溯，靠的是redo log写入
根本原因不是“变聪明了”，而是自增值变更被当作数据变更一样记进了redo log。MySQL 8.0启动时会重放redo日志，从中提取出最后一次成功的自增计数器值，再跟表中当前MAX(id)比大小，取较大者+步长作为新起始值。
这意味着：即使你删光了所有数据，只要之前插入过id=10000的记录，重启后AUTO_INCREMENT仍会是10001（假设步长为1），不会退回到1。
关键点：
-
redo log里记录的是“已分配但未提交”的自增值吗？不是——只记录**已成功分配并写入引擎层**的值，事务回滚不影响它 - 崩溃恢复时，如果redo log里有
AUTO_INCREMENT=5000，而表里MAX(id)=4999，最终值就是5000；如果表里MAX(id)=5002，那最终值就是5003 - 这个机制只对
InnoDB生效，MyISAM仍走老路（但基本不用）
show create table看到的AUTO_INCREMENT值，其实是内存快照
执行SHOW CREATE TABLE时显示的AUTO_INCREMENT=xxx，是当前InnoDB字典缓存里的值，不是磁盘上持久化的“权威值”。它可能滞后于redo log里的最新分配值，尤其在高并发插入后还没触发检查点时。
真正可靠的参考是：SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='tbl_name'。这个值由server层从数据字典读取，和重启后恢复逻辑一致。
常见误判场景：
- 刚插入一条
id=100，立刻SHOW CREATE TABLE看到AUTO_INCREMENT=101→ 正常 - 接着删除
id=100，再SHOW CREATE TABLE仍显示101→ 也正常，删除不改计数器 - 但此时重启，恢复后的值仍是
101，不会变成100→ 和5.7行为本质区别
为什么唯一键冲突后ID仍递增，且不回滚
这是InnoDB设计上的主动取舍：避免锁竞争。当插入因Duplicate entry失败时，自增值已经由引擎层分配并写入redo log，回滚它需要额外加锁、校验、补偿，会严重拖慢高并发写入性能。
所以MySQL 8.0延续了这一策略——“分配即生效”，哪怕语句最终失败。这也是你看到ID不连续的最常见原因。
典型链路：
- 执行
INSERT INTO t (c) VALUES (2)，其中c有唯一索引，且已有c=2 - InnoDB获取当前
AUTO_INCREMENT=100，设为新行id=100，并把100写入redo log - 检测到
c=2冲突，返回错误，但AUTO_INCREMENT已升为101 - 下一次成功插入，
id就是101，跳过了100
升级到8.0后仍要警惕的兼容性细节
持久化解决了重启回溯问题，但没解决“不连续”本身。如果你的业务强依赖ID连续（比如用ID做分页游标、或导出序号），依然会出问题。
特别注意这些边界：
- 显式插入大于当前
AUTO_INCREMENT的值，比如INSERT INTO t(id) VALUES(9999)，会导致计数器直接跳到10000，后续普通插入就从这里开始 -
TRUNCATE TABLE会重置计数器（即使8.0），因为它重建表结构，相当于新建一张表 - 如果用
mysqldump导出再导入，CREATE TABLE语句里带AUTO_INCREMENT=xxx，导入后计数器就从这个值起步，和原库可能不一致
最易被忽略的一点：innodb_autoinc_lock_mode配置仍影响并发插入行为（如INSERT ... SELECT），只是不再影响持久性。别以为升级完就万事大吉，该调的参数还得调。
