REPLACE INTO必然触发自增ID跳跃，因其本质是DELETE+INSERT两步操作：冲突时先删旧行，再插入新行，INSERT阶段必分配新自增值且不可复用，即使显式指定ID或冲突发生在非主键字段亦如此。
REPLACE INTO 为什么必然触发自增 ID 跳跃
因为它的底层就是 DELETE + INSERT，不是“原地更新”。只要发生唯一键（PRIMARY KEY 或任意 UNIQUE 索引）冲突，MySQL 就会先删掉旧行，再执行一次全新插入——而 INSERT 阶段一定会申请下一个自增值，哪怕你显式指定了 id 字段，只要该列没出现在 REPLACE INTO 的列列表中，InnoDB 就仍会分配新 ID。
常见错误现象：Duplicate entry 'x' for key 'PRIMARY' 没报错，但业务日志里发现 created_at 时间被重置、软删除标记丢失、外键关联数据意外级联删除——这些都不是“更新”该有的行为。
- 即使表只有 1 行，执行一次
REPLACE INTO冲突，自增 ID 就跳 1 - 连续 5 次冲突，ID 就跳 5 步，中间空缺无法回收
- 如果唯一键是
email，主键是自增id，那么每次REPLACE都生成新id，旧id对应的行物理消失
REPLACE INTO 和 INSERT ... ON DUPLICATE KEY UPDATE 的核心区别
两者都处理唯一键冲突，但语义和实现完全不同：INSERT ... ON DUPLICATE KEY UPDATE 在检测到冲突后直接执行 UPDATE，不删行、不重新分配 ID、不重建索引、不触发 DELETE 触发器。
而 REPLACE INTO 必然走完整两阶段：先按唯一键定位并 DELETE（可能触发级联、触发器），再 INSERT（分配新自增 ID、重建所有索引、触发 INSERT 触发器）。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
REPLACE INTO产生的 binlog 包含DELETE_EVENT+INSERT_EVENT，体积更大，复制延迟更高 - 在百万级表上，QPS 比
INSERT ... ON DUPLICATE KEY UPDATE低 30%~50% - 若表有
ON DELETE CASCADE外键，REPLACE INTO的DELETE步骤会真实级联删其他表数据
主从复制环境下自增 ID 不一致的真实原因
问题不在语句本身，而在 MySQL 自增值的持久化机制差异。InnoDB 在 5.7 及更早版本中，AUTO_INCREMENT 值仅保存在内存；主库执行 REPLACE INTO 后，AUTO_INCREMENT 计数器递增并写入 binlog；但从库应用 binlog 时，只执行语句逻辑（删+插），并不同步主库的计数器值——它仍按本地 MAX(id)+1 推导下个值。
结果就是：主库 AUTO_INCREMENT=100，从库 AUTO_INCREMENT=98（因未同步计数器）。一旦主从切换，新主库（原从库）继续用 98 开始分配，很快撞上已存在的 id=99 或 id=100，报错 Error 1062: Duplicate entry '99' for key 'PRIMARY'。
- MySQL 8.0 起才通过 redo log 实现自增值持久化，缓解该问题
- Row 格式复制下，
REPLACE INTO的 binlog 事件仍不含自增计数器状态 -
SHOW CREATE TABLE输出的AUTO_INCREMENT=xxx是估算值，不可靠
什么情况下 REPLACE INTO 还能用
仅当满足全部以下条件时，才可谨慎考虑：REPLACE INTO 不是默认选择，而是权衡后的特例。
- 表无自增主键，或自增列不在业务关键路径（如不用于幂等判断、不暴露给前端）
- 无外键约束，或确认级联删除符合业务预期
- 无
BEFORE/AFTER DELETE触发器，或触发器逻辑与“删+插”语义兼容 - 主从架构已升级至 MySQL 8.0+，且明确开启自增持久化
- 监控已覆盖
information_schema.tables.AUTO_INCREMENT与MAX(id)差值告警
绝大多数场景下，INSERT ... ON DUPLICATE KEY UPDATE 更安全、更高效、副作用更可控。自增 ID 跳跃看似只是数字断层，背后暴露的是对“更新”语义的误读——真正难修复的，从来不是空缺的 ID，而是被悄悄删掉又重建的那条记录。
