REPLACE INTO本质是DELETE+INSERT：仅当表有主键或唯一索引时才触发替换，否则等同INSERT；任一唯一约束冲突即删旧行再插新行，导致自增ID跳变、binlog膨胀、外键级联、触发器重复执行及默认值重置等风险。
REPLACE INTO 不是更新，是删完再插——所有你以为的“覆盖”背后，都藏着一次 DELETE 和一次 INSERT。
REPLACE INTO 触发 DELETE + INSERT 的条件
只有当表存在 PRIMARY KEY 或任意一个 UNIQUE 索引时，REPLACE INTO 才会尝试“替换”；否则它就等价于普通 INSERT，可能造成重复数据。
只要任一唯一约束冲突（哪怕只是某条 UNIQUE 索引命中），MySQL 就会执行删除操作——注意：它不关心其他字段是否一致、也不判断你是不是只想改一个字段。
- 主键冲突 → 删除那 1 行，再插入新行
- 某个唯一索引冲突（如邮箱字段）→ 同样删除对应行，哪怕主键不同
- 多唯一索引同时冲突 → 仍只删 1 行（匹配到的第一条），但行为不可控，容易误判
自增 ID 跳变和 binlog 体积膨胀
因为本质是 DELETE + INSERT，所以 AUTO_INCREMENT 值不会复用。旧记录删掉后，新插入的行会拿到当前 AUTO_INCREMENT 值，然后该值再 +1 —— 即使你只是改了个邮箱，ID 也变了。
binlog 里会记录两条事件：DELETE EVENT 和 INSERT EVENT，而不是单条 UPDATE EVENT。实测在百万级表上，相同负载下 REPLACE INTO 产生的 binlog 比 INSERT ... ON DUPLICATE KEY UPDATE 大 40% 以上。
- 从库延迟风险更高（更多写入、更大日志）
- 基于 binlog 的解析工具（如 Canal、Debezium）会收到两次变更，需额外去重逻辑
- 无法通过
SHOW BINLOG EVENTS直观看出“这是更新”，只能看到删和插
外键、触发器与时间字段被悄悄重置
REPLACE INTO 不触发 BEFORE UPDATE 或 AFTER UPDATE 触发器，只可能触发 BEFORE INSERT 和 AFTER INSERT（以及对应的 DELETE 类触发器）。如果子表有 ON DELETE CASCADE，旧记录一删，关联数据就没了。
更隐蔽的问题是字段默认值覆盖：没显式写的字段（比如 created_at、status）会按建表定义填充——NOT NULL DEFAULT CURRENT_TIMESTAMP 会重设时间，NOT NULL DEFAULT 'active' 会把原本改成 'inactive' 的状态又刷回去。
- 依赖
created_at做幂等判断的业务逻辑会失效 - 外键设为
ON DELETE RESTRICT时，REPLACE INTO直接报错：Cannot delete or update a parent row: a foreign key constraint fails - 想只更新
updated_at？必须把整行字段全列出来，否则其他字段会被默认值覆盖
什么场景下还能用 REPLACE INTO
真能用的场景极少，且必须同时满足：
- 你明确需要「整行替换」，而非局部更新
- 表无外键依赖，也无
ON DELETE级联或RESTRICT约束 - 自增 ID 是否连续、是否跳变对你完全无影响（例如缓存表、配置快照表）
- 你能确保每次提供全部必要字段，或默认值对业务安全
绝大多数业务更新（用户资料、订单状态、库存扣减）都应该用 INSERT ... ON DUPLICATE KEY UPDATE。它的语义清晰、开销低、副作用可控——而 REPLACE INTO 的“方便”背后，全是容易被忽略的物理删除动作。
