MySQL 5.7的AUTO_INCREMENT重启后回溯是设计使然：计数器仅存于内存dict_table_struct.autoinc，未持久化；重启后执行SELECT MAX(id)+1重建，导致值变小。
MySQL 5.7 的 AUTO_INCREMENT 值只存在内存里
这不是 bug，是明确的设计行为：AUTO_INCREMENT 计数器在 InnoDB 中仅保存于内存结构 dict_table_struct.autoinc，不写入任何磁盘介质。只要 MySQL 进程退出（无论是 service mysqld restart 还是异常崩溃），这个值就彻底丢失。
重启后，InnoDB 必须“猜”下一个该用什么值，它执行的逻辑等价于：
SELECT MAX(id) FROM t FOR UPDATE
这个查询结果加一，就是新的 AUTO_INCREMENT 值。所以它不是“重置为 1”，而是“按现存数据最大 ID 重新推算”。
哪些操作会让重启后 AUTO_INCREMENT 变小？
常见触发场景包括：
- 删掉当前最大 ID 的行（比如现有 ID 是 1,2,3,4，删掉
id=4，重启后新值变成 4，而不是原来的 5） -
DELETE FROM t清空表（MAX(id)为NULL，结果取默认偏移量auto_increment_offset，通常是 1） - 手动插入一个远大于当前最大 ID 的值（如当前最大是 100，却
INSERT INTO t(id) VALUES(200)；重启后只看现有数据，可能回落到 101）
注意：TRUNCATE TABLE 会立即重置内存计数器，但和 DELETE 一样，重启后效果相同——都依赖 MAX(id)+1 重建。
SHOW CREATE TABLE 显示的 AUTO_INCREMENT=XX 不可信
这个值直接从内存读取，不是查磁盘。它只是“当前认为下一个该用几”，而这个“认为”本身不持久。你执行一次 INSERT 或显式指定 ID 后，它会变；但只要没写盘，重启就归零。
验证很简单：
- 插入 3 行 →
SHOW CREATE TABLE显示AUTO_INCREMENT=4 -
DELETE FROM t WHERE id = 3→ 再查，仍显示4（内存未更新） - 重启 MySQL → 再查，大概率变成
3（因为现存最大 ID 是 2）
同理，SHOW TABLE STATUS LIKE 't'\G 返回的 Auto_increment 字段，在 5.7 中也是内存值，不可靠。
和 MySQL 8.0 的关键区别在哪
8.0 把每次 AUTO_INCREMENT 变更都写入 redo log，并在 checkpoint 时持久化到数据字典系统表。这意味着：
- 重启后值不变，
SHOW CREATE TABLE真实可信 -
ALTER TABLE t AUTO_INCREMENT = N在 8.0 中会真正生效并跨重启保留；5.7 中只在内存改，重启即被覆盖 - 异常崩溃后首次插入不再需要
FOR UPDATE锁表查MAX(id)，避免阻塞
最容易被忽略的一点：即使你确认版本是 5.7，也要检查 innodb_autoinc_lock_mode 和 auto_increment_offset 配置——它们不影响回溯本质，但在 5.7.27 前，后者在线修改时存在主键冲突的修复缺陷。
