MySQL 5.7及更早版本重启后AUTO_INCREMENT回退是正常设计：计数器仅存于内存，重启时执行SELECT MAX(id)+1重建，不保留历史分配值；8.0起通过redo log和数据字典持久化，重启后保持原值。
MySQL 5.7 及更早版本重启后 AUTO_INCREMENT 回退是正常行为
这不是 bug，而是设计如此：InnoDB 的自增计数器只保存在内存中，服务重启时会执行 SELECT MAX(id) FROM t FOR UPDATE 来“猜”下一个值。如果表里最大 ID 是 100，但你曾手动插入过 200，之后又删掉 200，重启后计数器就会回落到 101 —— 它只看现存数据，不记得历史分配过什么。
这种回退在 5.7 环境下必然发生，且无法通过配置禁用。如果你的业务依赖“ID 单调递增不回落”（比如下游系统用 ID 做幂等判断、分页游标或日志追踪），必须升级或绕行。
MySQL 8.0+ 默认持久化，但需确认实际部署版本
8.0 起，InnoDB 将自增值变更写入 redo log，并在 checkpoint 时落盘到数据字典，重启后恢复的是上次已提交的值，不再查 MAX(id)。你可以用以下命令验证：
SELECT @@version; —— 必须是 8.0.30 或更高；
SHOW CREATE TABLE t; —— 输出中 AUTO_INCREMENT=xxx 的值就是当前持久化值，重启后仍一致。
注意两个易忽略点：
– MyISAM 表仍走老逻辑，哪怕在 8.0 环境下；
– 如果你用 ALTER TABLE t AUTO_INCREMENT = N 手动调大，这个 N 在 8.0 中会被持久化，在 5.7 中重启即失效。
5.7 环境下避免回退冲突的实操方案
升级是最彻底的解法，但若暂不能升级，可从应用层规避主键冲突风险：
- 禁止显式插入小于当前
MAX(id)的 ID，尤其避免INSERT INTO t(id, ...) VALUES (1, ...)这类语句 - 建表时设足够大的起始值：
CREATE TABLE t (id INT PRIMARY KEY AUTO_INCREMENT) AUTO_INCREMENT = 1000000;，预留缓冲空间 - 所有 INSERT 都不指定 ID，让 MySQL 全权管理；如需可控编号（如订单号），改用单独的
sequence表或 UUID + 时间戳组合 - 若已出现冲突，不要靠
ALTER TABLE ... AUTO_INCREMENT = N强行压小值——MySQL 会静默修正为MAX(id) + 1，毫无提示
真正危险的是人为干预后的“隐性不一致”
比重启回退更难排查的，是开发或 DBA 手动执行过 ALTER TABLE t AUTO_INCREMENT = 500，而表中已有 id=1000 的记录。此时 MySQL 不报错，但后续插入会直接主键冲突。这种问题不会在重启时暴露，而是在某次正常 INSERT 时突然炸出来。
所以生产环境任何对 AUTO_INCREMENT 的修改，都必须先查 SELECT MAX(id) FROM t;，确保目标值严格大于它。没有例外。
