show create table 看不到持久化配置，因为自增持久化是 mysql 8.0 内嵌的默认机制，非可开关参数；它通过 mlog_table_dynamic_meta 日志写入 redo log 实现，不可禁用，也不在 my.cnf 或表定义中体现。
MySQL 8.0 默认已启用自增主键持久化，无需额外配置 —— 它通过写入 redo log 实现，不是靠开关控制的“功能”，而是底层机制升级。
为什么执行 SHOW CREATE TABLE 看不到持久化相关配置？
因为这不是一个可显式开启/关闭的参数。持久化逻辑内嵌在 InnoDB 的元数据更新流程中，由新增的 MLOG_TABLE_DYNAMIC_META redo 日志类型承载。你不会在表定义或 my.cnf 里看到类似 innodb_autoinc_persist=ON 这样的选项 —— 它是 MySQL 8.0+ 的默认行为，不可禁用。
常见误解：有人试图找 auto_increment_persist 或类似变量，结果查不到。这是正常的，它压根不存在。
重启后自增值从哪来？不是靠 SELECT MAX(id) 吗？
在 MySQL 8.0 中，重启时 InnoDB 会优先从 redo log 中恢复自增计数器值；只有当该值不可用（比如 redo 被截断、或表首次打开且无对应日志）时，才退回到传统方式：SELECT MAX(ai_col) FROM table_name FOR UPDATE。
- 这意味着：只要正常关闭、且 redo 未被覆盖，重启后
AUTO_INCREMENT值就是上次分配的准确延续 - 但如果发生异常崩溃 + redo 日志被 checkpoint 清理过，就可能回退到
MAX(id)+1，此时会出现“看似不持久”的现象 - 可通过
SELECT @@innodb_redo_log_capacity;和检查ib_logfile*大小，评估 redo 覆盖风险
备份恢复后自增值变小了，是持久化失效了吗？
不是失效，而是 XtraBackup 等物理备份工具在恢复时，不会重放备份时间点之后的 redo 日志 —— 所以自增计数器只能基于恢复时刻的数据文件重建，即再次走 MAX(id)+1 路径。
这会导致两种典型现象：
- 备份前
AUTO_INCREMENT=6038085，恢复后SHOW CREATE TABLE显示AUTO_INCREMENT=6038081 - 新插入一行，ID 分配为 6038081，而非预期的 6038086
- 这不是 bug，是物理备份的固有限制：redo 日志未随备份一起保存或未被正确应用
解决办法只有手动修正：ALTER TABLE t1 AUTO_INCREMENT = 6038086;（注意该语句只设置下限，不校验是否已存在）
哪些操作仍会导致自增空洞？持久化管不了这些
持久化解决的是「重启丢失」问题，但不修复「分配即消耗」逻辑。以下行为依然产生空洞，且无法避免：
- 删除某行后，其 ID 永远不会被复用（哪怕重启后）
-
INSERT ... SELECT并发执行时，innodb_autoinc_lock_mode=2会预分配 ID 段，段内未用完的 ID 直接废弃 - 事务回滚：已分配的自增值不退还
- 唯一键冲突导致的插入失败，也会推进计数器
真正要连续 ID，别依赖 AUTO_INCREMENT —— 改用应用层序列号、UUIDv7 或数据库外的分布式 ID 生成器。MySQL 的自增主键本质是“高效分配器”，不是“紧凑编号器”。
