MySQL 8.0 自增初始值“乱了”并非 bug，而是因自增值改由磁盘持久化且仅在INSERT或ALTER TABLE后更新，不再依赖重启时MAX(id)推算；SHOW CREATE TABLE才是唯一实时可信的查看方式。
MySQL 8.0 升级后自增初始值“乱了”，大概率不是 bug，而是你没注意到自增值持久化机制已变 —— 它现在真会写进磁盘，但只在每次 INSERT 或 ALTER TABLE ... AUTO_INCREMENT= 后才刷入系统表，而不是像老版本那样靠重启时查 MAX(id) 猜。
为什么升级后 AUTO_INCREMENT 值看起来“跳变”或“回退”
MySQL 8.0 把自增值存在 mysql.innodb_table_stats 和引擎私有系统表里，并通过 redo log 持久化。但这个值只在以下情况更新：
-
INSERT新行（且未显式指定主键）时，计数器递增并落盘 -
ALTER TABLE t AUTO_INCREMENT = N显式设置后立即落盘 - 正常关闭 + 启动时从系统表读取（不是从
MAX(id)计算）
所以如果你在 5.7 时代手动删过最大 ID 的记录、又没触发过 INSERT，升级到 8.0 后首次启动读到的可能仍是旧的“高水位”值；反之，如果升级前刚执行过 ALTER TABLE ... AUTO_INCREMENT=1000，那 8.0 就真会从 1000 开始，哪怕表里当前最大 id 才 500 —— 这就是所谓“乱了”的根源。
SHOW CREATE TABLE 是唯一可信的当前自增值来源
别信 information_schema.tables.auto_increment，它在 8.0 中不实时更新，也不反映内存/系统表里的真实值。真正能立刻看到当前生效的自增起点，只有：
SHOW CREATE TABLE `your_table`;
输出里 AUTO_INCREMENT=xxx 那一栏才是当前计数器值。常见误区：
- 用
SELECT MAX(id) FROM t推算 —— 8.0 不这么干，结果常偏低 - 查
information_schema视图 —— 该视图底层缓存严重，重启后可能延迟数分钟才刷新 - 依赖
ANALYZE TABLE—— 它只更新统计信息，跟自增值无关
如何安全重置自增起点（避免主键冲突）
如果确认要重设，必须满足两个前提：表无并发写入、业务接受后续 ID 跳跃。操作顺序不能错：
- 先清空表用
TRUNCATE TABLE t—— 它会重置自增值为 1（且不可回滚） - 若只是删数据没 truncate，必须显式执行：
ALTER TABLE t AUTO_INCREMENT = N，其中N至少为MAX(id) + 1，否则下次INSERT可能报Duplicate entry - 不要用
DELETE FROM t+ALTER TABLE ... AUTO_INCREMENT=1组合 —— 在 8.0 下，DELETE不触发自增值落盘，ALTER才写，但若中间有其他写入，可能覆盖
升级后最易被忽略的兼容性坑
8.0 的自增值持久化是“事件驱动”而非“状态快照”，这意味着：
- 主从复制中，如果从库是 5.7，主库是 8.0，
AUTO_INCREMENT行为不一致，可能导致从库插入失败 - 使用
mysqldump --single-transaction备份再恢复到 8.0，dump 文件里带AUTO_INCREMENT=xxx，恢复后该值直接生效 —— 但若原表在 dump 期间有写入，这个值就过期了 - 某些 ORM（如旧版 Django）会缓存建表语句里的
AUTO_INCREMENT值，升级后没清理缓存，可能误判主键范围
真正麻烦的从来不是值本身，而是不同组件对“当前自增起点”这件事的理解错位 —— 查的时候用错接口，设的时候没等落盘，同步的时候版本混搭，三者任一出问题，ID 就“乱”得毫无规律。
