MySQL 8.0自增ID不回收已删值是设计使然，因计数器仅基于当前最大ID或redo log持久值递增，DELETE不触发回退，显式指定ID或ALTER TABLE可手动干预但不自动跳过空洞。
MySQL 8.0 的自增列不会自动“回收”或“跳过”已删除的 ID，这是设计使然——AUTO_INCREMENT 只关心当前最大值，不感知中间空洞。想让它“跳过已删 ID”，本质上是在误解它的行为；真正能做的，是手动干预下一次生成值，或接受空洞存在。
为什么 DELETE 后自增值不会回退？
MySQL 8.0 将自增计数器持久化到 redo log，重启也不丢。它只在插入时读取当前表中 MAX(id)（或从持久化值恢复），然后加 auto_increment_increment 得到下一个值。DELETE 不会触发计数器重置，哪怕删光全表。
- 执行
DELETE FROM users WHERE id = 5;→ 表里少了一行，但AUTO_INCREMENT值不变 - 再
INSERT INTO users (name) VALUES ('Alice');→ 新 ID 仍是MAX(id) + 1，比如从 6 变成 7，不是 5 - 即使
TRUNCATE TABLE users;也会重置计数器（因为它是 DDL），但普通 DELETE 永远不会
如何让下一条插入“跳过”某个已删 ID？
只能显式指定 ID 值，或临时调高自增起点。注意：这不是“跳过”，而是“绕过”。数据库本身不提供“跳过已删 ID”的自动机制。
- 直接插入指定 ID：
INSERT INTO users (id, name) VALUES (5, 'Alice');—— 成功的前提是该 ID 当前未被占用，且表允许显式写入自增列（无NO_AUTO_VALUE_ON_ZERO限制） - 调整下一次自增值：
ALTER TABLE users AUTO_INCREMENT = 6;—— 这会让下次隐式插入从 6 开始，但若 5 已被删而未被占，它仍可能被后续显式插入用掉 - 如果目标是“永远不复用 5”，那就别管它，业务层记录黑名单或用 UUID 替代——MySQL 不负责 ID 回收
常见误操作与后果
试图靠 ALTER TABLE ... AUTO_INCREMENT = X 来“填空”，容易引发主键冲突或逻辑混乱。
-
ALTER TABLE users AUTO_INCREMENT = 5;后插入，结果是 5 → 如果 5 已存在（比如被显式插入过），报错ERROR 1062 (23000): Duplicate entry '5' for key 'PRIMARY' - 在主从复制环境下，显式插入中间 ID 可能导致从库冲突，尤其开启 GTID 时更难跳过
-
SET INSERT_METHOD = FIRST;或类似配置对 InnoDB 无效，该变量仅用于 MERGE 引擎，早已弃用
最易被忽略的一点：自增 ID 的“空洞”不是 bug，是并发安全的代价。强行填空反而破坏唯一性保障和复制稳定性。真有合规或审计要求必须连续，应改用应用层序列号服务，而非依赖 MySQL 自增。
