mysql 8.0中auto_increment值持久化依赖redo log，重启后不重置；xtrabackup若未处理尾部mlog_table_dynamic_meta日志会导致恢复后回退，需升级工具或手动修复。
AUTO_INCREMENT 值本身不直接参与索引结构重建，但它决定新插入行的主键值，而主键就是聚簇索引。一旦这个值在恢复后错乱，就会导致后续写入破坏索引有序性或引发唯一冲突——所以它不是“索引恢复”的一部分，而是“索引安全写入”的前提。
MySQL 8.0重启后AUTO_INCREMENT值为何不再重置？
因为计数器被写入 redo log 并在检查点刷入 mysql.innodb_table_stats（内部系统表），而非仅靠 SELECT MAX(ai_col) FROM table_name FOR UPDATE 推导。这意味着：
- 即使表中最大主键是
100，但上次分配到105，重启后仍从106开始，不会倒退 - 该值在
SHOW CREATE TABLE输出的AUTO_INCREMENT=xxx中可见且真实生效 - 备份工具（如
xtrabackup）若未正确处理redo尾部的MLOG_TABLE_DYNAMIC_META日志，可能漏掉最后几条自增值更新，导致恢复后AUTO_INCREMENT回退（这就是你看到的6038081而非6038086的原因）
innodb_autoinc_lock_mode=2 和持久化不是一回事
很多人混淆这两个机制：
-
innodb_autoinc_lock_mode=2控制并发插入时 ID 预分配行为（比如INSERT ... SELECT），解决的是性能与顺序问题，不影响重启一致性 - 自增持久化解决的是单次写入后、跨重启的连续性问题；哪怕
lock_mode=0，只要用了 8.0+，计数器也持久 - 两者叠加时，预分配段（如
1001–1010）若未用完就崩溃，未消耗的 ID 会永久空洞，但下一段起点仍基于持久化的最大已分配值
Xtrabackup 恢复时AUTO_INCREMENT丢失的典型表现
现象：备份恢复后，SHOW CREATE TABLE 显示 AUTO_INCREMENT=6038081，但实际数据里已有 id=6038085 的记录。
- 根本原因是
xtrabackup在 prepare 阶段只应用到checkpoint LSN，而自增值更新日志（MLOG_TABLE_DYNAMIC_META）可能位于redo尾部未被覆盖的活跃区域，被跳过 - 临时修复可用
ALTER TABLE tbl AUTO_INCREMENT = N手动设高，但必须确保N > MAX(id)，否则下次插入直接报Duplicate entry - 长期方案是升级到
xtrabackup 8.0.30+或改用mysqlbackup（官方热备工具），它们显式识别并重放这类元数据 redo
AUTO_INCREMENT 持久化依赖 redo log 的完整性，而很多运维脚本在清理旧 ib_logfile* 或强制截断日志时，会意外丢弃尚未 checkpoint 的自增元数据——这不是 bug，是设计使然。
