mysql 8.0 并未解决自增主键空洞问题，空洞是设计使然；它真正解决的是重启后自增值回退或重复的持久性问题，通过将自增值变更写入 redo log 实现崩溃恢复后准确还原，同时默认启用 innodb_autoinc_lock_mode=2 提升并发插入性能，但不消除空洞。
MySQL 8.0 并没有「解决」自增主键空洞问题——空洞是设计使然，不是 bug；它真正解决的是「重启后自增值回退/重复」这个更危险的问题。
为什么 AUTO_INCREMENT 会有空洞？根本原因不在版本
空洞（比如插入 3 行后 AUTO_INCREMENT=6）本质来自自增值的分配逻辑，和 MySQL 版本无关：
- 显式插入大于当前值的 ID（如
INSERT INTO t(id) VALUES(100)），InnoDB 会把AUTO_INCREMENT更新为MAX(id)+1 -
INSERT ... ON DUPLICATE KEY UPDATE仍会预分配一个 ID，即使最终走更新分支，该 ID 也被消耗 -
INSERT IGNORE遇到唯一冲突时，同样会预先申请 ID，然后丢弃 - 事务中插入后回滚，ID 不回收（InnoDB 从不回退已分配的自增值）
这些行为在 5.7 和 8.0 中完全一致。所谓“修复”，只针对「持久性」层面。
MySQL 8.0 的真实改进：自增值写入 redo log
在 5.7 及之前，AUTO_INCREMENT 值仅存于内存（dict_table_t::autoinc），实例重启后执行 SELECT MAX(id)+1 重建——这会导致两个严重问题：
- 如果表中最大 ID 是 100，但刚删了一行，
MAX(id)变成 99，重启后AUTO_INCREMENT就变成 100，而 100 已存在 → 主键冲突 - 主从切换或备份恢复时，若从库重启，可能复用已被主库用过的 ID → 数据不一致
MySQL 8.0+ 把每次自增值变更（如插入、ALTER TABLE ... AUTO_INCREMENT = N）都记入 redo log，崩溃恢复时重放日志即可还原准确值。你可以验证：
mysql> SHOW CREATE TABLE t\G ... AUTO_INCREMENT=1001
这个值现在是可靠的，不会因重启突变。
innodb_autoinc_lock_mode=2 是默认，但别误以为它能填空洞
MySQL 8.0 默认启用交错模式（innodb_autoinc_lock_mode=2），它只影响并发插入时的锁粒度和 ID 分配顺序，比如：
- 多个
INSERT ... SELECT并发执行时，不再阻塞彼此，各自按需预分配一段 ID（如 1001–1010、1011–1020） - 但它不改变「已分配即消耗」规则：哪怕某段里只插了 1 行，剩下 9 个 ID 也永远空着
- 如果你依赖连续 ID 做分页或范围查询，
innodb_autoinc_lock_mode调整毫无帮助
想观察效果，可对比执行：INSERT INTO t(c1) SELECT c1 FROM t LIMIT 1000 在 mode=1 vs mode=2 下的 AUTO_INCREMENT 跳变幅度。
ALTER TABLE 修改列类型时，自增属性容易丢失
这是实操中最常踩的坑之一，尤其在扩容 ID 类型时：
-
ALTER TABLE t MODIFY id BIGINT;→ 自增属性直接消失，后续插入会报ERROR 1364 (HY000): Field 'id' doesn't have a default value - 必须显式保留：
ALTER TABLE t MODIFY id BIGINT AUTO_INCREMENT; - 更安全的做法是分两步：
ALTER TABLE t CHANGE id id BIGINT;+ALTER TABLE t AUTO_INCREMENT = <current_max>;</current_max>
注意：SHOW CREATE TABLE 输出里的 AUTO_INCREMENT=xxx 是当前计数值，不是定义的一部分；它不参与 DDL 复制，也不保证字段本身带 AUTO_INCREMENT 属性。
空洞无法避免，但重启不跳号、主从不冲突、修改列不丢属性——这些才是 MySQL 8.0 真正落地的保障。业务层若强依赖连续 ID，得自己维护序列号表，别指望 AUTO_INCREMENT。
