REPLACE INTO 本质是 DELETE + INSERT 而非 UPDATE，会改变自增 ID、触发两次触发器、可能误删行；应优先使用 INSERT ... ON DUPLICATE KEY UPDATE 实现安全覆盖写入。
REPLACE INTO 本质是 DELETE + INSERT，不是 UPDATE
MySQL 的 REPLACE INTO 看似像“覆盖写入”，实际执行逻辑是：先按主键或唯一索引尝试查找匹配行；若存在，就先 DELETE 该行，再执行 INSERT 新值。这意味着自增 ID 会变化、触发器会触发两次（DELETE 和 INSERT 各一次）、外键级联操作可能被意外触发。
常见错误现象：REPLACE INTO users (id, name) VALUES (1, 'Alice') 执行后发现 id 变成了新值（比如 2），或者审计日志里出现两条记录（删一条、插一条）。
- 只适用于表有主键或至少一个
UNIQUE索引，否则退化为普通INSERT - 如果表有多个唯一索引，只要任一索引冲突就会触发删除+插入，不一定是主键冲突
-
REPLACE INTO不支持ON DUPLICATE KEY UPDATE那样的条件更新逻辑
替代方案：优先用 INSERT ... ON DUPLICATE KEY UPDATE
绝大多数“覆盖写入”场景，INSERT ... ON DUPLICATE KEY UPDATE 更安全、更可控。它真正执行的是“存在则更新”，不会改变自增 ID，也不会重复触发 DELETE 相关逻辑。
例如：
INSERT INTO users (id, name, updated_at) VALUES (1, 'Alice', NOW()) ON DUPLICATE KEY UPDATE name = VALUES(name), updated_at = NOW();
注意：VALUES(col) 表示 INSERT 子句中该列的原始值，不是当前行的旧值。
- 只更新指定字段，未列出的字段保持原值（不像
REPLACE INTO会全量重写） - 性能更好：避免了 DELETE + INSERT 的两阶段 I/O 和索引重建开销
- 兼容性更强：标准 SQL 中无
REPLACE INTO，但ON DUPLICATE KEY UPDATE是 MySQL 显式支持且文档清晰的语法
REPLACE INTO 的真实适用场景很窄
只有当你明确需要“强制重置整行状态”，且能接受 ID 变更、触发器双触发、外键约束重新校验时，才考虑 REPLACE INTO。典型例子：缓存表、配置快照表、或某些幂等导入脚本中要求“完全以新数据为准”。
- 如果表有
AUTO_INCREMENT主键，且业务依赖 ID 连续性或外部引用，REPLACE INTO会导致 ID 跳变 - 如果定义了
BEFORE DELETE或AFTER INSERT触发器，它们都会被执行，顺序是：BEFORE DELETE → AFTER DELETE → BEFORE INSERT → AFTER INSERT - 使用前务必确认所有唯一索引的语义——比如邮箱和手机号都设了 UNIQUE，那么改邮箱时若手机号已存在，也会误删原记录
执行前必须检查唯一索引定义
REPLACE INTO 是否生效、删哪一行，完全取决于表上有哪些 UNIQUE 约束。一个常见的坑是：开发以为只按主键判断，结果因为加了个 UNIQUE(email)，导致插入同邮箱不同 ID 的记录时，把老用户删了。
查清楚当前行为的命令：
SHOW CREATE TABLE users;
重点关注输出中的 UNIQUE KEY 行。如果有多个，REPLACE INTO 会按索引顺序匹配第一个冲突项（InnoDB 中通常是建表时最先定义的那个唯一索引）。
- 不要在生产环境临时加 UNIQUE 索引后直接用
REPLACE INTO，风险极高 - 如果只是想避免重复插入，用
INSERT IGNORE更轻量，它遇到冲突直接跳过，不删也不更新 - 批量写入时，
REPLACE INTO的性能波动比INSERT ... ON DUPLICATE KEY UPDATE大得多，尤其在高并发下容易引发锁等待
真正要靠“覆盖”来保证数据一致性时，得先理清到底要覆盖什么：是部分字段？整行状态？还是仅避免重复？选错语法，后面排查主键跳变、触发器异常、外键失败，花的时间远超写对一行 SQL 的成本。
