MySQL 的 REPLACE 和 INSERT ON DUPLICATE KEY UPDATE 有什么区别？

知识点详解：少写一个字段，结果为什么完全不同？

用一条记录看“替换”与“更新”

假设 profile 表中，id 是主键，note 默认值为 none。现有记录是 id=7、name=旧名、note=需要保留。

如果执行：

REPLACE INTO profile (id, name) VALUES (7, '新名');

它表达的是插入一条新记录并替换冲突旧行。没有写 note，新行就使用 note 的默认值，而不是继续保留“需要保留”。

如果需求只是改昵称，可以表达为：

INSERT INTO profile (id, name) VALUES (7, '新名') AS incoming
ON DUPLICATE KEY UPDATE name = incoming.name;

这里使用 MySQL 8.4 支持的行别名形式。冲突时只更新 name，旧 note 不在更新表达式中，因此保留。旧的 VALUES(column) 引用形式已被弃用，版本说明见 Upsert 文档。

这些是 SQL 语义，不需要再复制成 TypeScript/Python 代码。应用层无论用哪种语言，都需要参数绑定，而不是拼接不可信字符串。

REPLACE 不一定只影响一条旧记录

表如果有两个唯一键，新行可能通过不同字段分别与两条旧行冲突。REPLACE 可能移除多个冲突旧行，再插入新行。

所以“有就更新，没有就新增”不足以概括它。具体规则见 REPLACE 文档。

存储引擎内部可能优化实际执行方式，但对应用应按删除与插入语义理解，不能据此把它当普通 UPDATE。

图：一次替换，可能冲突两条旧行。

为什么触发器、自增和外键要一起检查？

删除与插入，和修改原行的效果可能不同。删除、插入触发器可能参与执行；外键可能导致拒绝或级联；未显式保留的自增身份和默认字段，也可能改变。

因此，审查 REPLACE 时不能只看最后 name 是否正确，还要看关联记录、审计日志及其他字段。对用户资料这类需要保留身份和历史信息的记录，替换语义尤其要谨慎。

Upsert 也不是忽略所有冲突

它需要明确冲突依据。多个唯一键可能使匹配对象不符合预期；更新表达式本身也可能产生新的唯一键冲突。

实际设计应先确定记录的业务身份，尽量让冲突选择明确，再验证更新表达式。

并发与幂等也要分开：数据库可以让单条语句以相应事务和锁规则执行，但如果重试一次就再次 count=count+1，重复调用仍然会重复累加。请求是否重复，需要另外识别。

面试官继续追问

affected rows 等于 2，代表改了两条记录吗？

不能脱离语句和客户端选项判断。REPLACE 的计数包含删除与插入；Upsert 的新增、更新和无变化也有特定计数规则。应按具体 API 核对。

REPLACE 比 Upsert 快吗？

没有统一结论。先满足数据语义，再在真实索引、冲突比例和触发器条件下比较。不能为了性能把更新换成删除插入。

没有唯一键，两者能识别相同业务记录吗？

不能自动识别。没有对应唯一约束，就不能仅凭相同业务内容触发预期冲突处理。

面试速记卡

• REPLACE：冲突时按删除旧行、插入新行理解。
• 缺省列：新行使用默认值，不自动保留旧值。
• Upsert：冲突时执行指定更新表达式。
• 审查：唯一键、触发器、外键和身份字段。
• 幂等：单条语句原子执行不代表重复调用无副作用。