mysql 8.0 自增主键重启后不回溯，show create table 是唯一可信的当前 auto_increment 值，因其直读 innodb 数据字典内存结构；information_schema.tables.auto_increment 不实时刷新，仅反映统计快照。
MySQL 8.0 的自增主键重启后不会回溯 —— 如果你观察到“回溯”，说明你看到的不是真实自增值，而是缓存值、误读了 information_schema，或表在升级前就已处于异常状态。
为什么 SHOW CREATE TABLE 是唯一可信的当前 AUTO_INCREMENT 值
MySQL 8.0 把自增计数器写入 redo log 和引擎私有系统表（如 mysql.innodb_table_stats），但 information_schema.tables.auto_increment 不实时刷新，可能延迟数分钟甚至更久；它底层走的是统计信息快照，不是内存/磁盘计数器直读。
-
SHOW CREATE TABLE t直接从 InnoDB 数据字典内存结构读取，是当前生效的准确值 -
SELECT MAX(id) FROM t永远不能代表下一条 INSERT 的 ID，8.0 不再基于它推算 -
ANALYZE TABLE t只更新统计信息，对自增值无任何影响 - 重启后若发现
AUTO_INCREMENT比预期小，大概率是升级前 5.7 表中残留的旧高水位被持久化下来了（比如升级前刚执行过ALTER TABLE t AUTO_INCREMENT = 1000）
为什么升级后 AUTO_INCREMENT 看起来“跳变”或“偏低”
这不是 bug，是 8.0 持久化机制和你操作时序共同作用的结果：
- 自增值只在
INSERT（未显式指定主键）或ALTER TABLE ... AUTO_INCREMENT = N时落盘 - 如果表在 5.7 时代删过最大 ID 记录，又没触发 INSERT，升级到 8.0 后首次启动仍会加载旧的持久化值（比如 1000），哪怕当前
MAX(id)是 500 - 反之，如果升级前刚执行过
ALTER TABLE t AUTO_INCREMENT = 1，那 8.0 就真从 1 开始 —— 即使这会导致主键冲突 - 没有“自动对齐
MAX(id)+1”逻辑，8.0 宁可“跳”也不“退”
如何安全重置自增起点（避免 Duplicate entry）
重置必须满足两个硬前提：表无并发写入、业务接受后续 ID 跳跃。顺序错一步就可能出错：
- 想彻底归零？用
TRUNCATE TABLE t—— 它重置计数器为 1，且不可回滚 - 只是删了数据没 truncate？必须显式执行
ALTER TABLE t AUTO_INCREMENT = N，其中N至少为(SELECT COALESCE(MAX(id), 0) + 1 FROM t) - 绝对不要用
DELETE FROM t+ALTER TABLE t AUTO_INCREMENT = 1组合：DELETE 不触发落盘，ALTER 才写，但若中间有其他 INSERT，新写入的值会被覆盖 - 执行前务必确认没有正在运行的写事务，否则
ALTER可能被阻塞或与并发 INSERT 冲突
真正容易被忽略的点是：8.0 的“持久化”不等于“智能对齐”。它忠实记录你最后一次明确设置或 INSERT 推进的值，不管这个值是否合理。所以升级后第一眼看到的 AUTO_INCREMENT，往往是你自己（或旧版本逻辑）埋下的伏笔，而不是 MySQL 突然失智。
