MySQL 8.0重启后AUTO_INCREMENT不会重置——它通过redo log和系统表持久化，启动时取已分配最大值与MAX(id)较大者加步长；SHOW CREATE TABLE值非实时，真正可信的是当前内存字典值或崩溃恢复后计算结果。
不会重置。MySQL 8.0 正常重启后 AUTO_INCREMENT 值不会变小，更不会“重置”回 1 或 MAX(id)+1 —— 这是常见误判，根源在于你查的值不权威、操作没触发持久化路径，或者混淆了 TRUNCATE 与重启。
为什么 SHOW CREATE TABLE 显示的 AUTO_INCREMENT 值不准
SHOW CREATE TABLE 输出里的 AUTO_INCREMENT=xxx 是建表或最后一次 ALTER TABLE ... AUTO_INCREMENT=N 时的声明值，不是当前真实水位。它不随插入自动更新，也不反映 redo log 里已落盘的最新分配值。
- 插入 100 行后，
SHOW CREATE TABLE可能还显示AUTO_INCREMENT=50（批量预分配导致） - 删光数据后执行
DELETE FROM t，该值完全不变；但TRUNCATE TABLE t会把它强制设为 1 并清空持久化记录 - 真正可信的当前起点是：
SELECT COALESCE(MAX(id), 0) + 1 FROM t（前提是没显式插入过更大 ID）
重启后值“变小”只可能来自这三件事
MySQL 8.0 的崩溃恢复逻辑是：从 redo log 读出已分配的最大自增值，再和表中 MAX(id) 比大小，取较大者 + 步长。这个过程本身绝不会让值倒退。
-
TRUNCATE TABLE t：唯一合法且主动重置行为，会把计数器归 1，并删除持久化状态 -
ALTER TABLE t AUTO_INCREMENT = N（N ≤ 当前最大 ID）：MySQL 允许设小值，但下次插入会从 N 开始，可能撞主键 - 从 MySQL 5.7 备份恢复到 8.0：若备份不含 redo log 或系统表，恢复时退化为
MAX(id)+1初始化，可能比原值小
为什么刚升级到 8.0 就发现 AUTO_INCREMENT “乱跳”
升级本身不改值，但 8.0 启动时读的是磁盘上残留的旧系统表值（如 mysql.innodb_table_stats），而不是像 5.7 那样现场算 MAX(id)+1。如果你在 5.7 时代删过最大 ID、又长期没插入，升级后首次启动读到的可能是“高水位”旧值。
- 升级前刚执行过
ALTER TABLE t AUTO_INCREMENT = 10000→ 8.0 真从 10000 开始，哪怕表里最大 id 才 500 - 升级前长期只
DELETE不INSERT→ 8.0 启动时可能沿用多年前的“高水位”，看起来像“跳号” - 别依赖
information_schema.TABLES.AUTO_INCREMENT：该字段缓存严重，重启后可能延迟数分钟才刷新
如何安全调整自增起点（避免 Duplicate entry）
必须满足两个前提：表无并发写入、业务接受 ID 跳跃。顺序不能错：
- 要彻底清空并重排 ID：用
TRUNCATE TABLE t（不可回滚，重置为 1） - 仅删数据未 truncate：先查最大 ID：
SELECT MAX(id) FROM t，再执行ALTER TABLE t AUTO_INCREMENT = N，其中N至少为MAX(id) + 1 - 禁用
DELETE FROM t+ALTER TABLE ... AUTO_INCREMENT=1组合：DELETE 不触发落盘，ALTER 才写，中间若有其他插入，AUTO_INCREMENT值会被覆盖
真正容易被忽略的点是：InnoDB 的自增计数器一旦分配（哪怕事务回滚），就永久占用，不会回收。批量插入、INSERT SELECT、高并发写入都会造成“空洞”，这不是 bug，是为性能做的取舍。
