先说结论：MySQL自增ID在数据库重启后出现回溯，这个现象基本出现在MySQL 5.7及更早版本的InnoDB表上。而到了8.0+，默认配置下该问题已经得到解决。
MySQL 5.7及以前：自增值仅驻留内存，重启后回溯的根源
旧版InnoDB将AUTO_INCREMENT计数器存储在内存中，具体位于表对象的内存结构dict_table_struct.autoinc内。它既不写入磁盘，也不记录redo日志。因此，无论是执行正常的service mysqld restart，还是遭遇服务器突然崩溃，只要mysqld进程退出，该值就会立即丢失。
重启时，MySQL通过执行类似SELECT MAX(id) + 1的逻辑来重建计数器，这正是导致自增值回溯的根本原因。常见的触发场景包括：
- 删除最大ID记录（例如
DELETE FROM t WHERE id = 100）后重启 → 此时MAX(id)变为99，新生成的AUTO_INCREMENT自然变成100，这就是所谓的“回退”现象。 - 使用
DELETE FROM t清空表后重启 →MAX(id)变为NULL，结果直接采用默认偏移量，通常为1。 - 手动插入显式ID（如
INSERT INTO t(id) VALUES(500)）后重启 → 内存中“下一个应分配的值”丢失，完全依赖MAX(id)+1，很可能导致重复或跳号。
MySQL 8.0+：通过redo日志持久化自增计数器
MySQL 8.0+ 引入了一项关键改进：每次成功分配一个AUTO_INCREMENT值，都会像普通数据变更一样将其写入redo log，并在检查点（checkpoint）时同步到数据字典表。启动时，首先重放redo日志，获取最后已分配的值，然后与当前表中MAX(id)比较，取较大值再加上步长，作为新的起点。
这意味着：
- 即使清空了全部数据，只要历史记录中曾插入过
id=10000，重启后AUTO_INCREMENT依然是10001，绝不会回退到1。 - 需要注意的是，
SHOW CREATE TABLE展示的AUTO_INCREMENT=xxx仅是一个内存快照，可能存在延迟。准确的当前值应通过以下查询获取：SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t'。 - 事务回滚不会影响已分配的自增值，因为该值已在引擎层写入redo日志。这是MySQL在性能与一致性之间主动做出的权衡。
MyISAM表为何不存在自增ID回溯问题？
MyISAM的AUTO_INCREMENT值直接存储于索引文件.MYI的头部，每次修改都会立即写入磁盘，重启时原样读取。但需注意，MyISAM不支持事务，崩溃恢复能力较弱，在生产环境中已基本被弃用。
容易被忽略的关键细节
即使在MySQL 8.0+版本中，使用ALTER TABLE t AUTO_INCREMENT = N手动设置自增起始值时，N必须大于等于当前表中MAX(id) + 1，否则下一次INSERT操作可能会报Duplicate entry错误。此外，请牢记：这一持久化机制仅适用于InnoDB引擎，且完全依赖于redo log的完整性——如果磁盘损坏导致日志丢失，仍可能退化到MySQL 5.7的行为。
