MySQL没有原生MERGE INTO语法，官方直到8.0.33仍不支持；替代方案中，REPLACE INTO本质是“删+插”，会导致ID变更、级联删除和双触发器问题，而INSERT ... ON DUPLICATE KEY UPDATE才是语义最接近、更安全的实现。
MySQL 有没有原生 MERGE INTO？
没有。MySQL 官方直到 8.0.33 仍不支持 MERGE INTO 语法，直接写会报错：ERROR 1064 (42000): You have an error in your SQL syntax。Oracle 的 MERGE 是原子性“存在则更新、不存在则插入”，而 MySQL 必须用其他组合方式模拟——REPLACE INTO 是最接近的替代，但行为有本质区别。
REPLACE INTO 看似能用，但为什么常出错？
REPLACE INTO 不是“更新或插入”，而是“删+插”：先按主键或唯一索引尝试删除已有行，再执行插入。这意味着：
- 如果表有自增主键，
REPLACE INTO会导致 ID 变更（旧行被删，新行获得新 ID） - 外键约束开启时，可能触发级联删除（取决于
ON DELETE设置） - 触发器（
BEFORE DELETE/AFTER INSERT）会被执行两次，逻辑可能错乱 - 如果唯一键冲突来自非主键字段（比如
UNIQUE(email)），REPLACE INTO会删掉整行，哪怕主键值没变
例如：REPLACE INTO users (id, name, email) VALUES (1, 'Alice', 'alice@new.com'); —— 若 email 是唯一键且已存在，MySQL 会删掉原 id=1 行，再插一条新 id（可能变成 2），完全违背“只改邮箱”的本意。
真正安全的类 MERGE 实现：INSERT ... ON DUPLICATE KEY UPDATE
这才是 MySQL 中语义最接近 Oracle MERGE 的方案。它基于唯一约束（主键或任意 UNIQUE 索引）判断冲突，仅更新指定列，不改变主键、不触发删除逻辑。
用法示例：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
INSERT INTO users (id, name, email, updated_at) VALUES (1, 'Alice', 'alice@new.com', NOW()) ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email), updated_at = NOW();
关键点：
-
ON DUPLICATE KEY UPDATE只在发生重复键错误时生效，否则就是普通插入 -
VALUES(col)引用的是本次INSERT语句中该列的值，不是当前行旧值 - 可以只更新部分字段（比如只更新
updated_at，不碰name） - 若表有多个唯一索引，只要任一索引冲突就会触发更新（注意设计唯一键的粒度）
什么时候才该考虑 REPLACE INTO？
仅当满足全部以下条件时，REPLACE INTO 才可作为简化手段：
- 表无外键引用，或你明确接受级联影响
- 主键是业务无关的代理键（如自增
id），且应用层不依赖其稳定性 - 所有唯一约束都由主键承担（即没有额外
UNIQUE字段） - 不需要保留原行的某些不变字段（如
created_at、version）
否则，INSERT ... ON DUPLICATE KEY UPDATE 是默认应选方案。它的执行计划更可控，日志更清晰，也更容易加条件判断（比如配合 WHERE 子句做更细粒度控制）。
真正容易被忽略的是：很多人把 REPLACE INTO 当作“语法糖”，却没意识到它底层是两步操作（DELETE + INSERT），在高并发下可能造成间隙锁扩大、binlog 多写、从库延迟等问题——这些在 ON DUPLICATE KEY UPDATE 中都不存在。
