replace into 本质是 delete + insert，非原子更新：先删除旧行再插入新行，导致两次写入、索引重建、自增id跳变、外键级联和触发器重复执行等问题。
Replace Into 本质是 Delete + Insert，不是原子更新
MySQL 的 REPLACE INTO 不是“覆盖更新”，而是先尝试插入，冲突时删除旧行再插入新行。这个过程会触发两次写入、两次索引维护，并可能引发自增 ID 跳变、外键级联动作、触发器重复执行等问题。
常见错误现象：Duplicate entry 'X' for key 'PRIMARY' 没报错，但业务逻辑以为只是“改了数据”，实际旧记录已物理删除——比如依赖 created_at 字段做幂等判断的场景会出问题。
- 仅当表有
PRIMARY KEY或UNIQUE索引时才会触发替换逻辑，否则退化为普通INSERT - 若存在多个唯一索引，只要任一索引冲突就会触发 DELETE（哪怕其他唯一键不冲突）
- 自增主键在 DELETE 后不会回填，
REPLACE INTO必然导致 ID 跳增
Replace Into 和 Insert Into ... On Duplicate Key Update 性能差异明显
REPLACE INTO 需要先定位旧记录（索引查找）、再执行 DELETE（标记+清理）、再 INSERT（分配新行、重建所有索引），而 INSERT ... ON DUPLICATE KEY UPDATE 在检测到冲突后直接原地更新，跳过删除和重新插入开销。
实测在百万级单主键表上，相同负载下 REPLACE INTO 的 QPS 比 ON DUPLICATE KEY UPDATE 低 30%~50%，且产生的 binlog 更大（含 DELETE EVENT + INSERT EVENT）。
-
REPLACE INTO无法只更新部分字段，必须提供完整行值（缺失列按默认值填充） -
ON DUPLICATE KEY UPDATE支持col = VALUES(col)语法复用 INSERT 值，避免重复写字段名 - 若业务只需更新个别字段（如
status或updated_at），ON DUPLICATE KEY UPDATE是更轻量的选择
Replace Into 可能破坏外键约束或触发器语义
因为 REPLACE INTO 是 DELETE + INSERT 组合，如果子表有 FOREIGN KEY ... ON DELETE CASCADE，旧记录删除会连带清除子表数据；而 ON DUPLICATE KEY UPDATE 不触发 DELETE，自然不触发级联。
同样，定义在父表上的 BEFORE DELETE / AFTER DELETE 触发器会被执行，BEFORE INSERT / AFTER INSERT 也会执行——相当于一次操作激活了两套生命周期钩子。
- 若子表依赖父表主键做逻辑关联（非外键约束），DELETE 后 INSERT 可能导致子表短暂“找不到父记录”
-
REPLACE INTO在事务中仍遵循两阶段行为：DELETE 提交前，INSERT 就可能被其他事务看到（取决于隔离级别和锁范围） - 使用
REPLACE INTO前务必检查是否有ON DELETE行为或关键触发器，否则容易引发隐性数据丢失
什么情况下真的需要 Replace Into？
极少数场景下，REPLACE INTO 不可替代：比如需要强制重置某些不能通过 UPDATE 修改的字段（如 created_at、id），或依赖其“先删后插”特性来重建索引/触发物化视图刷新逻辑。
但更常见的做法是显式拆解：DELETE ... WHERE key = ? + INSERT ...，这样能控制事务边界、规避自增 ID 异常、明确表达意图。
- 不要为了省一行 SQL 用
REPLACE INTO，它隐藏了太多副作用 - 线上高频写入场景，优先压测
INSERT ... ON DUPLICATE KEY UPDATE是否满足需求 - 若必须用
REPLACE INTO，记得在注释里写清“此处依赖 DELETE 侧效应”，方便后续维护者理解
真正麻烦的从来不是语法会不会写，而是删掉的那一行，有没有人还在查它。
