REPLACE INTO本质是DELETE+INSERT而非更新：冲突时先删旧行再插新行，导致自增ID变化、触发器执行两次、未指定字段重置为默认值，仅适用于需整行覆盖的场景。
Replace Into 本质是删再插，不是真“更新”
MySQL 的 REPLACE INTO 看起来像“存在就更新”，实际执行逻辑是：先按主键或唯一索引尝试插入，如果冲突，就先 DELETE 原有行，再 INSERT 新行。这意味着自增 ID 会变化、触发器会触发两次（DELETE + INSERT）、外键级联动作可能被意外触发——它不是 UPDATE，也没有 ON DUPLICATE KEY UPDATE 那种原子性更新行为。
常见错误现象：REPLACE INTO users (id, name, created_at) VALUES (1, 'Alice', NOW()) 执行后发现 id 没变但 created_at 被重置了，或者触发器里记录的日志多了一条 DELETE。
- 只在明确需要“覆盖式替换”（比如缓存表、临时同步表）时才用
REPLACE INTO - 如果只是想保留原
created_at、只更新部分字段，必须改用INSERT ... ON DUPLICATE KEY UPDATE - 注意自增列：即使你没显式指定自增字段，
REPLACE也会分配新值，旧值不会复用
Replace Into 必须依赖主键或唯一索引才能生效
没有主键或唯一索引的表上执行 REPLACE INTO，效果和 INSERT INTO 完全一样——它根本不会触发“替换”逻辑，因为没有冲突判定依据。
使用场景举例：向一张带 UNIQUE KEY (email) 的用户表写入数据，邮箱重复时希望覆盖基本信息：
REPLACE INTO users (email, name, updated_at) VALUES ('a@b.com', 'Bob', NOW());
但如果表结构只有普通索引或没索引，这条语句只会不断插入新行，毫无“存在即更新”的效果。
- 执行前务必确认目标字段上有
PRIMARY KEY或UNIQUE约束 - 复合唯一索引也支持，比如
UNIQUE KEY (tenant_id, code)，这时冲突判断基于两个字段组合 - 不能靠业务层“查是否存在再决定用 REPLACE”，那失去意义；约束才是 MySQL 判定冲突的唯一依据
Replace Into 对 AUTO_INCREMENT 和触发器的影响很实在
每次 REPLACE 成功触发删除+插入，都会导致自增计数器递增，哪怕你没显式插入自增列。同时，如果定义了 BEFORE DELETE 或 AFTER INSERT 触发器，它们都会被调用——这和直觉里的“更新”完全不同。
性能影响：相比 INSERT ... ON DUPLICATE KEY UPDATE，REPLACE 多一次 DELETE + INSERT 的开销，尤其在大表或高并发下更明显；还可能引发间隙锁范围扩大。
- 检查
SHOW CREATE TABLE xxx中是否含AUTO_INCREMENT，再评估 ID 跳变是否可接受 - 若有审计类触发器（如记录操作日志），要确认是否允许 DELETE + INSERT 这种双事件模式
- 在复制环境（尤其是基于语句的 binlog）中，
REPLACE产生的 DELETE + INSERT 可能比单条 UPDATE 更难被从库并行回放
真正安全的“存在即更新”该用 ON DUPLICATE KEY UPDATE
绝大多数所谓“存在即更新”需求，其实应该用 INSERT ... ON DUPLICATE KEY UPDATE。它不改变原有行 ID，不触发 DELETE 相关逻辑，只更新指定字段，语义清晰且可控。
示例：仅更新 name 和 updated_at，保留原始 created_at：
INSERT INTO users (id, name, created_at, updated_at) VALUES (1, 'Alice', '2020-01-01', NOW()) ON DUPLICATE KEY UPDATE name = VALUES(name), updated_at = NOW();
注意 VALUES(col) 是引用 INSERT 子句中对应列的值，不是函数调用。
- 支持多字段更新，可用
IF()、CASE做条件赋值 - 冲突时不会修改未列出的字段，安全性更高
- 返回的
affected rows：1 表示插入，2 表示更新（MySQL 5.7+ 默认行为）
别被名字误导，“Replace Into”不是更新语法，它是带副作用的替代操作；真要稳妥更新，就老实用 ON DUPLICATE KEY UPDATE。
