先说结论你现在表里已经有 1 到 5手动插入了一条 id15 的记录那么接下来让 MySQL 自动生成主键拿到的不会是 15也不会是 5而是16。这个问题看着简单但背后牵扯到 MySQL 自增计数器的存储逻辑、版本差异、批量插入锁模式等一系列知识点。很多人只记住了“自增主键会取当前最大值加 1”这个粗略规则一旦遇到“手动插过更大的 ID”或者“删掉了最大 ID”的情况就会判断失误。我尽量用实际场景把这块讲透顺带解决你以后可能会踩的同类坑。1. 先回答不是 15也不是 5而是 161.1 一个容易理解的类比取号机把 MySQL 的 AUTO_INCREMENT 理解成银行排队时的取号机你会更容易抓住本质。取号机里有一个“当前号码计数器”它永远记住的是“下一个号码是多少”。当你按一下取号机吐出一张 6 号计数器立刻变成 7。你手里的号是 6和计数器已经没关系了。就算拿到 6 号的人后来走了、叫号没叫到、甚至号被撕了取号机的计数器依然是 7不会因为 6 号没人要就回退到 6。MySQL 的自增主键同理。自增计数器维护的是“下一个要分配的值”不是“当前表里有多少行”。这个认知是所有后续判断的基础。1.2 手动插入 15 时数据库内部发生了什么假设表结构很简单CREATE TABLE t_user ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(50), PRIMARY KEY (id) );当前表里已有 1 到 5 共 5 条数据计数器原本是 6。此时手动执行INSERT INTO t_user (id, name) VALUES (15, 张三);InnoDB 在执行这条语句时会发现显式指定的 15 大于当前计数器 6。为了保证后续自动生成的主键不会跟 15 冲突它会把计数器直接更新为 16。所以这条手动插入执行完成后表的真实状态是表里数据1、2、3、4、5、15当前自增计数器16也就是下一个自增值你下一次再执行INSERT INTO t_user (name) VALUES (李四)MySQL 会自动分配 id16。之后是 17、18……一直顺着往上走绝不会再回到 6 那个区间。注意一个细节手动插入 15 之后下一个值是 16不是 15。因为 15 已经被这条记录占用了自增逻辑不会重复分配已存在的值。1.3 一张表看懂各种“手动插 ID”之后的计数器我把常见手动插入场景和结果整理成了下面的表格你可以对照自己的实际场景来判断。假设当前表里最大 id 是 5计数器是 6。手动插入的 id结果插入后计数器下一个自增值1 到 5 中已存在的值主键冲突插入失败不变66等于当前计数器插入成功777 到 14 之间任意值插入成功该值 1该值 115大于计数器插入成功1616判断规则其实一句话显式插入的值如果大于等于当前计数器计数器就会被顶到这个值再加一如果小于当前计数器计数器纹丝不动。你标题里的场景正好命中最后一行所以答案非常明确从 16 开始继续自增跟 5 已经没有关系了。2. 自增计数器的本质它记的是“下一个号”不是“最大行”2.1 计数器并不是从表里现算出来的不少文章说“自增主键就是 MAX(id)1”这个说法在大多数连续插入的场景下是成立的因为它描述了常态表里最大 id 是 5下一个自然就是 6。但一旦出现这些操作这个“口诀”就会失效手动插入了一个较大的 id然后又删掉它一个事务里插入了数据但最终回滚批量插入时预分配了区间但实际只用了部分执行过 INSERT ... ON DUPLICATE KEY UPDATE明明没插入新行id 却跳了这些场景里表里最大 id 可能很小但计数器已经很大。计数器和表内实际数据的“最大行”是两个独立的东西。我们不能从 max(id) 反推计数器当前值也不能从计数器当前值反推表里有多少行。2.2 计数器与 MAX(id) 为什么会不一致删除操作是造成二者不一致最常见的原因。比如正常插入数据变成 1 到 10计数器为 11手动插入一条 id100 的数据计数器跳到 101删除 id100 这条数据此时表里最大 id 是 10但计数器仍然是 101。如果你用“MAX(id)1”的思路会觉得下一个自增值是 11但实际情况是InnoDB 并不会因为删除了 100 就把计数器降回去下一个自增值依然是 101。这条特性在 MySQL 8.0 之前和之后表现还略有差异我下一章详细讲。这里只需要确立一个观念自增计数器是独立的“状态”它被某些操作推高之后不会自动回落。2.3 那些消失的 ID回滚、删除与预分配你可能会问为什么 MySQL 不把计数器设计成“每次分配时查一下当前表里最大 id再加一”这样不就能自动回落了理论上可以但实际上代价太大。自增分配是高并发路径上的高频操作每次插入都要执行一次SELECT MAX(id)去扫数据页性能损耗无法接受。更关键的是两个并发事务同时查到 max 都是 5都准备插入 id6就必然有一个要撞主键失败。只有让计数器在内存里原子递增才能保证并发下每个事务拿到的值都不一样。所以 MySQL 选择了“浪费一些 id换取性能和唯一性”。删除、回滚、预分配都会产生空洞但这些空洞是保证不冲突的必要成本。你看到的 id 不连续不是 bug是设计使然。3. MySQL 5.7 和 8.0 的差异重启后答案可能不同3.1 8.0 之前重启后从 MAX(id) 重新数MySQL 8.0 之前InnoDB 的自增计数器只保存在内存里不会持久化到磁盘。每次数据库重启后InnoDB 相当于失忆了只能通过扫描表里的数据找到当前最大的 id然后基于它重建计数器。这意味着什么回到你的场景表里有 1 到 5手动插入 id15计数器变 16如果你此时把 id15 这条记录删掉了然后重启 MySQL重启后表里最大 id 是 5InnoDB 会把计数器重建为 6。也就是说删掉 15 之前计数器明明是 16重启之后下一个自增值变成了 6。15 这个曾经存在过的痕迹在计数器的世界里被彻底抹掉了。如果表里没有做“删掉大 ID”这个操作那么无论重启多少次计数器都会根据 max(id)15 重建为 16结果跟插入时保持一致。3.2 8.0 之后计数器被持久化不再回退MySQL 8.0 改变了这一行为。从 8.0 开始InnoDB 把自增计数器的每次变化都持久化到了 redo log 里重启后可以直接恢复出最新的计数器值不再需要扫描表数据去推算。换句话说你插入 id15计数器变 16即使随后你删掉了 15即使数据库重启计数器依然保持 16。下一次自增值还是 16不会因为表里最大 id 变成 5 而回退。这个改进解决了一个老问题以前在高并发写入下重启后计数器可能被重置到一个较小的值进而导致主键冲突或重复分配。现在计数器状态更可靠了代价是那些“删除大 ID 后想靠重启回收号段”的老办法失效了。3.3 一个真实发生过的坑删掉最大 ID 后重启主键竟然被复用我在维护老项目时踩到过类似的坑。当时的业务场景是测试环境导入了一批数据最大 id 是 5000导入完以后发现不用了就把数据清掉了保留了表结构。按“自增会继续往上”的预期下一条数据应该从 5001 开始结果实际插入后 id 却是 6。原因就是我们用的是 MySQL 5.7清空数据没有用 TRUNCATE而是 DELETE 删除所有行。表里最大 id 变成空表重启后 InnoDB 按“没有数据则从 1 开始”的逻辑重建了计数器所以分配出了 6。更麻烦的是如果之前业务里有记录引用过旧的 6 号 id这条新插入的数据会占用同一个主键值在关联查询时发生串数据。这提醒我一件事只要系统沿用自增主键就别轻易让计数器回退到现在曾经使用过的区间。如果确实需要清空表并重新从 1 开始应该用 TRUNCATE而不是 DELETE 配合重启。如果你是 8.0 用户这个坑基本不存在了。但如果你还在维护 5.7 或更早版本升级时也要注意重启后计数器行为的变化可能会暴露一批“以为删了就没事”的历史问题。4. 还有一个隐藏开关innodb_autoinc_lock_mode4.1 三种锁模式分别管什么影响自增分配行为的除了版本还有一个重要的参数innodb_autoinc_lock_mode。这个参数控制 InnoDB 在分配自增值时使用什么样的锁策略它直接影响 ID 的连续性和并发性能。锁模式取值行为特点traditional0所有 INSERT 都使用表级 AUTO-INC 锁分配完全连续consecutive1默认简单插入用轻量级互斥锁批量插入用表级锁兼顾性能与连续interleaved2完全不使用表级锁高并发性能最好但 ID 可能交错分配MySQL 5.7 和 8.0 的默认值都是 1也就是 consecutive 模式。这个模式下单条简单 INSERT 的分配性能很高批量插入也能保持相对连续。4.2 为什么批量插入会让 ID 空洞更大很多人在“INSERT ... SELECT”之后发现 id 跳了几百甚至几千就是这个参数在起作用。拿你的场景继续扩展假设当前计数器已经是 16你执行一条INSERT INTO t_user (name) SELECT name FROM another_table LIMIT 100。在 consecutive 模式下InnoDB 为了确保整条语句分配到的 id 不被其他事务抢走会一次性申请一段区间。如果这条语句因为各种原因实际只插入了 50 行剩余的 50 个 id 也不会还给后续语句使用直接变成空洞。更常见的情况是插入过程中出现唯一键冲突比如要插入的 100 行里有几行重复语句回滚。看起来什么都没插进去但预分配的整段 id 可能就已经被消耗掉了下一次自增会从很远的地方开始。这种行为在并发场景下尤其明显。如果窗口期有其他简单 INSERT 在执行两个语句拿到的 id 区间甚至会是交错的表现出来就是表里的 id 好像毫无规律。4.3 主从复制下要谨慎使用交错模式很多追求极致写入性能的团队会把innodb_autoinc_lock_mode调成 2希望减少锁竞争。但这里有个隐藏风险在基于语句的 binlog 复制模式下主库分配自增值的顺序和执行语句的写入顺序可能不一致导致从库重放时拿到的主键跟主库不同。简单说就是主库上一条批量插入拿到了 id 区间 50 到 100但其中可能有一部分 id 被其他并发事务用掉了最终实际落库的数据 id 不连续从库重放 binlog 时按语句顺序重新分配结果可能完全对不上。长期累积主从两边的数据虽然内容一致但主键分布已经不同后续如果再涉及基于 id 的同步操作很容易出问题。所以我的建议是没有充分理由别把锁模式改成 2。你标题里的这个场景跟锁模式没有直接关系但理解这个参数能帮你解释很多“id 为什么跳得这么夸张”的疑问。5. 遇到类似问题怎么排查和修复5.1 查看当前计数器两种方法如果你的业务里也出现了手动插入大 ID 的情况第一时间应该确认当前计数器到底是多少。有两种方法方法一用 SHOW CREATE TABLESHOW CREATE TABLE t_user\G输出结果里会有一行AUTO_INCREMENT16这个就是下一条数据拿到的 id非常直观。方法二查询 information_schemaSELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA 你的数据库名 AND TABLE_NAME t_user;这个方法适合在程序里自动读取也可以用于监控告警。需要说明的是这个表里的值就是 InnoDB 当前内存中的计数器值不是估算值可以放心用。5.2 手动调整 AUTO_INCREMENT能设大不能乱设小如果计数器已经被顶到了一个不合适的值比如手动插入 15 之后又删掉了 15你希望后续从 6 开始继续发号可以手动修改ALTER TABLE t_user AUTO_INCREMENT 6;这里有一个关键前提这个设置值必须大于当前表内实际存在的最大 id否则会被 MySQL 忽略。比如表里现在最大的 id 是 15你把它改成 6不会生效实际计数器会变成 16。只有当 max(id) 是 5 或更小时改成 6 才合法。另外要特别注意手动把计数器往回调可能会导致之前用过的主键被重新分配。如果历史数据里有过 id6 的记录只是被删掉了那新插入的 id6 可能跟旧的引用关系产生语义混淆。生产环境操作前一定要确认好。5.3 迁移数据或导入旧 ID 时的标准操作数据迁移是手动插入大 ID 最常见的来源。比如从别的系统导数据保留了原表主键导入之后如果不做处理计数器可能仍然是 1下一次插入就会撞主键。标准做法分三步导入前先用 TRUNCATE 清空目标表保证没有残留数据导入时显式指定 id让数据完整落到表里导入完成后执行一次ALTER TABLE t_user AUTO_INCREMENT 当前最大id 1第 3 步是很多人容易漏掉的。虽然 InnoDB 在显式插入较大 id 时通常会自动把计数器顶上来但某些导入工具、临时表方案或特殊恢复流程可能会绕过这个机制。最稳妥的做法就是导入完主动确认一次SELECT MAX(id) 1 AS next_id FROM t_user;拿到结果后把 AUTO_INCREMENT 设成这个值。然后插入一条测试数据确认 id 符合预期再删掉测试数据即可。6. 我踩过的坑和给你的实际建议6.1 事务回滚ID 一样会跳有一次我在测试环境模拟并发写入开了事务插入了几行然后为了验证其他逻辑主动回滚了。当时想当然地认为“既然没插成功id 应该不会消耗”结果下一条正常插入的 id 直接从回滚前的位置继续了。原因前面已经说过InnoDB 分配自增值是在执行插入的过程中发生的分配完就把计数器递增了事务回滚并不会把计数器“还回去”。这看起来浪费但如果不这么做两个并发事务回滚后下一个事务就可能拿到跟已提交数据重复的 id。为了绝对不冲突只能牺牲连续。所以别再纠结那个回滚掉了的 id 去哪了它被“预留”走后就再也回不来了。6.2 INSERT ... ON DUPLICATE KEY UPDATE 也可能偷走 ID这类语句的设计本意是“有则更新无则插入”。但在 MySQL 的默认锁模式下即使最终因为唯一键冲突走了 UPDATE 分支自增计数器也可能已经被提前消耗了。我实测过一个简单例子表里只有一个唯一键插入一条已存在的记录触发更新逻辑看起来什么都没新增但查 SHOW CREATE TABLE 时发现 AUTO_INCREMENT 已经增加了 1。这条语句确实没有插入新行却把一个 id 号段“偷走”了。如果你的业务大量使用 ON DUPLICATE KEY UPDATE不要惊讶于自增 id 出现空洞这不是数据异常只是计数器的正常损耗。6.3 DELETE 不会重置计数器TRUNCATE 才会清表的时候很多人习惯用 DELETE FROM 删光数据然后等着计数器从 1 开始。实际上 DELETE 只是逐行删除数据计数器不会重置。想清空表且让自增归零必须用 TRUNCATE TABLE。不过 TRUNCATE 有一些限制比如被外键引用时会直接报错。如果有外键依赖要么先处理外键关系要么接受 DELETE 之后计数器继续往上走的事实。另外TRUNCATE 在 8.0 中也会重置计数器到 1这个行为跨版本一致。6.4 把自增主键当成“行号”是最常见的误区我在实际维护里见过不少同事为了“ID 不连续”而焦虑总想让主键变得 1、2、3、4、5 完美衔接。但自增主键的本质是唯一性标识不是行号。它只承诺不重复、趋势递增从来不承诺连续、不承诺没有空洞。如果你需要在页面上展示连续的序号正确做法是查询时用 ROW_NUMBER() 或者在应用层按结果集顺序编号绝不要依赖自增主键的连续性。手动插入大 ID 顶高计数器只是自增机制下的正常现象不影响数据的正确性不用特别处理。最后回到你最初的问题表里有 1 到 5手动插入 15 后后续自增会从 16 开始不会回到 5 的区间。如果你在 8.0 之前的版本里删掉了这条 15 并且重启了数据库它才可能“忘掉”这段历史那又是另一个故事了。