REPLACE INTO 实际执行 DELETE + INSERT 而非 UPDATE，会导致自增ID跳变、外键级联删除、触发器重复执行；仅对 PRIMARY KEY 或 UNIQUE 约束生效，NULL 值在唯一键中不触发替换，返回值为实际变更行数。
REPLACE INTO 会触发 DELETE + INSERT，不是 UPDATE
很多人以为 REPLACE INTO 是“有就更新、没就插入”的安全替代，其实它底层先尝试插入，冲突时直接删掉旧行再插新行。这意味着：自增 ID 会跳变、外键级联动作可能被意外触发、触发器（BEFORE/AFTER INSERT 和 DELETE）都会执行两次。
常见错误现象：Duplicate entry '123' for key 'PRIMARY' 报错没出现，但业务上发现 ID 不连续、关联表数据被删了、审计日志里多出一条 DELETE 记录。
- 使用场景：仅适合能接受“逻辑删除+重插”语义的场景，比如缓存表、幂等写入且无强外键依赖的中间表
- 如果主键/唯一键上有
ON DELETE CASCADE，REPLACE INTO可能连带删掉子表数据 - 性能影响：比
INSERT ... ON DUPLICATE KEY UPDATE多一次 DELETE 操作，尤其在大表或有索引维护开销时更明显
唯一键冲突才触发替换，普通索引无效
REPLACE INTO 只对定义为 PRIMARY KEY 或 UNIQUE 约束的列生效。如果只建了普通 INDEX（非唯一），即使值重复，也不会触发替换，而是直接报 Duplicate entry 错误并中断。
常见错误现象：建了个 INDEX (user_id, status)，然后用 REPLACE INTO t (user_id, status, updated_at) VALUES (123, 'active', NOW())，结果报错而不是覆盖——因为这个索引不带 UNIQUE。
- 检查方式：
SHOW CREATE TABLE t，确认冲突字段是否出现在PRIMARY KEY或UNIQUE KEY定义中 - MySQL 8.0+ 支持函数索引，但
REPLACE INTO仍只认显式声明的唯一约束，不识别基于表达式的唯一性 - 复合唯一键必须所有列都匹配才触发替换，少一个都不行
NULL 值在唯一键中的行为容易踩坑
MySQL 中，UNIQUE 约束允许任意数量的 NULL，因为 NULL != NULL。所以如果唯一键包含可空列，REPLACE INTO 对 NULL 值不会触发替换。
常见错误现象：表有 UNIQUE KEY (a, b)，已存在 (1, NULL)，再执行 REPLACE INTO t (a, b) VALUES (1, NULL)，结果是新插入一行，而不是替换——因为两个 NULL 不被认为“重复”。
- 解决办法：把字段设为
NOT NULL并给默认值（如''或-1），或改用INSERT ... ON DUPLICATE KEY UPDATE配合IFNULL()判断 - 注意：不同 SQL 模式（如
STRICT_TRANS_TABLES）下，隐式转NULL的行为也可能影响判断
REPLACE INTO 返回值含义和应用层处理
MySQL 执行 REPLACE INTO 后返回的受影响行数是“实际变更行数”，不是“语句执行次数”。插入成功返回 1；冲突后删+插，返回 2；如果删了 1 行又插了 1 行，就是 2；但如果删了 1 行、因其他约束失败导致插不进去，整个语句回滚，返回 0。
这和 INSERT ... ON DUPLICATE KEY UPDATE 的返回值逻辑完全不同（后者冲突更新返回 2，单纯插入返回 1）。
- 应用层不能靠返回值 == 1 来判断“是新增”，得结合业务逻辑或查库确认
- 事务中混用
REPLACE INTO和其他 DML 时，注意它的原子性是“整条语句”，但内部 DELETE 和 INSERT 分属不同步骤，锁行为更复杂 - 某些 ORM（如 Django 的
bulk_create(..., update_conflicts=...)）底层并不用REPLACE INTO，别想当然认为它等价
真正要小心的，是那个看似安静的 DELETE —— 它不报错、不提醒，但可能已经把关联数据、计数器、甚至下游监听的消息全带走了。
