mysql 5.7自增id重启后回溯是设计使然：auto_increment值仅存于innodb内存结构dict_table_struct.autoinc，未持久化；重启后执行select max(id)+1重建，导致“变小”。
MySQL 5.7 的自增主键重启后回溯，不是 bug，而是设计使然：AUTO_INCREMENT 值只存内存，不落盘。
为什么 SHOW CREATE TABLE 显示的 AUTO_INCREMENT=XX 会“变小”
这个值直接读自 InnoDB 表对象内存结构 dict_table_struct.autoinc，不是从磁盘查的。它反映的是“当前认为下一个该用几”，但这个“认为”一重启就清零。比如插入 4 条数据后 AUTO_INCREMENT=5，删掉 id=4 的行，SHOW CREATE TABLE 仍显示 5；但重启后，MySQL 重新执行 SELECT MAX(id) + 1，结果变成 4 —— 因为现存最大 id 是 3。
哪些操作会触发回溯，哪些不会
- DELETE 不改内存计数器，但重启后“丢失”的间隙会被填上（如删掉 4 和 5，重启后新插入可能拿到 4）
- 手动 INSERT 显式指定大 ID（如
INSERT INTO t(id) VALUES(200)），会更新内存计数器；但重启后只看现有数据最大值，可能回落到 101 - TRUNCATE TABLE 会重置计数器（且是 DDL，不可回滚），但 DELETE FROM t 不会——不过两者在重启后效果一样：都按
MAX(id)+1重建
和 MySQL 8.0 的关键区别在哪
8.0 把自增值变更写入 redo log，并在 checkpoint 时持久化到数据字典系统表；5.7 完全依赖内存 + 启动时临时查表。这意味着：
- 5.7 异常崩溃后首次插入可能阻塞（要加
FOR UPDATE锁查 MAX） - 5.7 的
ALTER TABLE t AUTO_INCREMENT = N只在内存生效，重启即失效；8.0 中这个 N 会被持久化 - MyISAM 没这问题，因为它把自增值直接写进
.MYI文件头——但 InnoDB 5.7 就是没存盘
最容易被忽略的兼容性陷阱
即使你确认版本是 5.7，也要检查实际部署环境是否混用了不同引擎或配置：
-
innodb_autoinc_lock_mode设为 0（传统模式）时，自增更保守，但不解决回溯；设为 2（交错模式）可提升并发，同样不解决回溯 -
auto_increment_offset和auto_increment_increment在 5.7.27 前存在重启后主键冲突的修复缺陷（尤其在线修改时） -
SHOW TABLE STATUS LIKE 't'\G返回的Auto_increment字段，在 5.7 中也是从内存读的，和SHOW CREATE TABLE一致，不可信
真正要靠住的只有两点：要么升级到 8.0+，要么业务逻辑彻底放弃对自增 ID 连续性、单调递增或“不回退”的任何假设。
