show create table 是查看当前 auto_increment 值的唯一可靠方式，因其直接读取内存中实时更新并经 redo log 持久化的计数器值；information_schema 和 max(id) 均不可信。
为什么 SHOW CREATE TABLE 才是看当前 AUTO_INCREMENT 的唯一方式
因为 MySQL 8.0 的自增计数器值只在内存中实时维护，且仅通过 redo log 持久化，information_schema.tables.auto_increment 视图底层缓存严重，重启后可能延迟数分钟才刷新，完全不可信。你执行 SELECT MAX(id) FROM t 得到的只是当前数据最大值，和计数器无关；ANALYZE TABLE 只更新统计信息，对自增值无任何影响。
真正反映当前生效的自增起点的，只有：
-
SHOW CREATE TABLE `your_table`输出里的AUTO_INCREMENT=xxx字段 - 该值在每次
INSERT（未显式指定主键）或ALTER TABLE t AUTO_INCREMENT = N后立即落盘并更新
自增计数器怎么写进 redo log 的
MySQL 8.0 引入了新的 redo log 类型 MLOG_TABLE_DYNAMIC_META，专门用于记录元数据变更。当自增计数器变化时（比如插入新行、显式设置 AUTO_INCREMENT），InnoDB 会生成一条该类型的 redo 日志，把新值写入磁盘。
这个过程不是每次递增都强制刷盘，而是由 checkpoint 机制协同控制：计数器变更先记日志，再在 checkpoint 前批量刷入引擎私有系统表（如 mysql.innodb_table_stats）。所以即使断电，崩溃恢复时也能从 redo log 中重建计数器内存值。
注意：UPDATE 或 DELETE 不触发计数器变更，也就不会写 redo log；只有 INSERT（含隐式自增）和 ALTER TABLE ... AUTO_INCREMENT= 才会。
为什么升级后 AUTO_INCREMENT 看起来“跳变”或“回退”
这不是 bug，是机制切换后的必然表现。关键点在于：8.0 不再像 5.7 那样靠重启时查 MAX(id) 推算初始值，而是直接读取上次落盘的计数器值。
常见导致“乱了”的场景包括：
- 5.7 时代手动
DELETE过高 ID 记录，但没触发过INSERT或ALTER，升级后首次启动读到的仍是旧高水位值 - 升级前刚执行过
ALTER TABLE t AUTO_INCREMENT = 1000，哪怕表里最大id是 500，8.0 就真从 1000 开始分配 - 使用
mysqldump --skip-auto-increment导入数据后没手动重设，导入语句里带了AUTO_INCREMENT=值，覆盖了原计数器
重置 AUTO_INCREMENT 要避开哪些坑
想安全重设，必须满足两个硬前提：表无并发写入、业务接受后续 ID 跳跃。操作顺序错一步就可能引发主键冲突。
推荐做法：
- 清空表用
TRUNCATE TABLE t—— 它会重置计数器为 1，且不可回滚，最干净 - 若只是删数据没 truncate，必须显式执行
ALTER TABLE t AUTO_INCREMENT = N，其中N至少为(SELECT MAX(id) FROM t) + 1，否则下次INSERT可能报Duplicate entry 'N' for key 'PRIMARY' - 绝对不要用
DELETE FROM t+ALTER TABLE t AUTO_INCREMENT = 1组合 ——DELETE不触发落盘，中间若有其他写入，ALTER设置的值可能被覆盖
最易被忽略的一点：ALTER TABLE ... AUTO_INCREMENT = N 的 N 必须严格大于当前表中已存在的最大主键值，哪怕那个值是人为 UPDATE 进去的 —— 8.0 不校验合法性，只按指令设置，冲突留给你自己收场。
