REPLACE INTO 实际是“删+插”掩盖冲突，非避免报错；它会引发自增ID跳变、时间戳重置、外键级联误删、触发器执行两次等副作用，且多唯一索引下行为不可控；ON DUPLICATE KEY UPDATE 才能精确更新指定字段、保留原ID与业务逻辑一致性。
REPLACE INTO 实际上不是“避免报错”，而是用删+插掩盖冲突
它根本不会避免报错——而是把 Duplicate entry 这类错误转成隐式 DELETE + INSERT 操作。你看到的“没报错”，其实是 MySQL server 层在内部拦截了唯一键冲突，并主动执行了删除逻辑。这会导致自增 ID 跳变、created_at 重置、外键级联误删、触发器执行两次等副作用。
常见错误现象：REPLACE INTO users (username, email) VALUES ('alice', 'a@b.com') 执行后发现原记录的 id 变了，updated_at 是当前时间，但业务逻辑依赖旧 id 或创建时间，结果出问题。
- 只要表有任意一个
PRIMARY KEY或UNIQUE KEY，REPLACE 就可能触发删除 - 如果多个唯一索引同时命中（比如
email和phone各撞一条不同记录），会删掉多行 - 返回的受影响行数 = 删除行数 + 插入行数，
mysql_affected_rows()返回 2 不代表成功更新，可能删了1行又插了1行
REPLACE INTO 在批量插入时性能更差，不是“更快的 ignore”
它比 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 多一次 DELETE 的 I/O、锁等待和 binlog 记录。尤其在高并发写入或大表场景下，容易引发锁等待甚至死锁。
使用场景非常受限：仅适合你明确需要“彻底替换整行 + 接受 ID 重分配 + 不关心触发器/外键影响”的极少数情况，比如缓存表、临时同步表。
- 每条 REPLACE 都要走完整索引查找 → 冲突检测 → DELETE → INSERT 流程
- DELETE 会释放自增 ID，后续插入可能跳号，干扰分页或监控指标
- binlog 中记录的是 DELETE + INSERT 两条事件，主从延迟或闪回时行为难预测
为什么 ON DUPLICATE KEY UPDATE 才是真正安全的替代方案
ON DUPLICATE KEY UPDATE 是唯一能精确控制“哪些字段更新、哪些保留原值”的语句。它不删不插，只改指定列，ID 不变、时间戳不重置、触发器不误触发。
示例：INSERT INTO users (id, username, email, updated_at) VALUES (1, 'alice_new', 'a_new@b.com', NOW()) ON DUPLICATE KEY UPDATE username=VALUES(username), email=VALUES(email), updated_at=NOW();
- 只在
id或username（如果有唯一索引）冲突时才更新，其他约束错误（如字段超长、NOT NULL 违反）仍会报错，便于定位真实问题 -
VALUES(col)引用的是本次 INSERT 的值，不是原值，避免误写成col = col + 1这类逻辑 - 支持批量插入多行，每行独立判断冲突并更新，无 ID 浪费风险
最容易被忽略的坑：REPLACE INTO 对多唯一索引的处理不可控
当一张表有主键 + 多个唯一索引时，REPLACE 的行为取决于哪个索引最先匹配到冲突行。MySQL 不保证顺序，也不允许你指定按哪个索引去重。这意味着同样一条语句，在不同版本、不同数据分布下，可能删掉完全不同的记录。
例如表 t(id PK, c INT UNIQUE, d INT UNIQUE)，执行 REPLACE INTO t(c,d) VALUES(1,2)：
- 若已有
c=1的记录 A 和d=2的记录 B，REPLACE 可能删 A、也可能删 B、甚至都删（取决于内部查找路径） - 这种不确定性在主从复制、备份恢复、审计追踪中会放大风险
- 而
ON DUPLICATE KEY UPDATE明确只响应第一个匹配的唯一键（通常是主键优先），行为可预期
