镝不咸1. 抓狂现场：明明有唯一索引，ON DUPLICATE KEY UPDATE 却"不生效"
先讲个我上周刚处理过的线上问题。业务方报了一个数据重复的 bug，说同一台设备短时间内产生了多条相同手机号的注册记录。我第一反应就是查代码，结果发现 insert 语句写得明明白白：
sql复制INSERT INTO user (phone, nickname, created_at)
VALUES ('13800138000', '新用户', NOW())
ON DUPLICATE KEY UPDATE nickname = VALUES(nickname);
phone 字段上明明有唯一索引，按道理第二次执行应该走更新分支，把昵称覆盖掉，而不是再插一条新记录。可现实就是表里出现了两条 phone 完全一样的行，唯一约束跟不存在一样。
最迷惑的地方在于，这条语句在测试环境怎么跑都没问题，一上生产就翻车。我当时排了很久，最后问题出在表结构上——生产库的 user 表里，phone 的唯一索引和另一张历史表合并时被 DBA 去掉了，只剩主键 id 上的唯一约束。也就是说，ON DUPLICATE KEY UPDATE 只认主键冲突，phone 重复根本触发不了 update 分支，于是静默地插入了一条新记录。
这个案例基本能概括标题里那个痛点：大家默认"ON DUPLICATE KEY UPDATE 就是用来做 upsert 的"，但很少有人认真想过，它到底在什么冲突下才会触发，尤其是非主键唯一字段参与的冲突，坑比想象中多得多。
这篇文章我想把这事彻底聊透。从语法本身的触发机制讲起，到多唯一键场景下的行为差异、业务落地时的正确姿势、MySQL 各版本之间的细微差别，以及生产环境里最容易踩的几个雷区，全部整理一遍。内容适合正在用或准备用这个语法做数据同步、批量导入、防重插入的同学，也适合被"唯一索引冲突"折腾过、想搞清楚底层原理的朋友。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. ON DUPLICATE KEY UPDATE 的触发机制，远不止主键冲突
2.1 唯一索引冲突也在捕获范围内
INSERT ... ON DUPLICATE KEY UPDATE 是 MySQL 对标准 SQL 的一个扩展，语义很直白：向表里插入一行数据，如果插入时发生主键冲突或唯一索引冲突，就用 UPDATE 分支里的表达式去更新已存在的那一行；如果没有冲突，就正常插入。
这里面很多人会漏掉的一点是：MySQL 官方文档明确说了"duplicate key"不仅指主键，任何定义了唯一索引（UNIQUE KEY）或唯一约束的字段冲突，都会被捕获。 所以理论上，只要 phone 上有唯一索引，上面那段 SQL 第二次执行时应该命中唯一键冲突，走进 UPDATE 分支。
但"理论上"三个字往往就是事故的开始。实际运行效果严重依赖表结构、索引定义、以及是否同时存在多个唯一键。我画过一张图给团队新人讲这个语法，核心就看三个判断点：
- 插入的值是否与已有行的主键冲突？
- 插入的值是否与任一唯一键索引冲突？
- 以上任一冲突发生时，UPDATE 分支会不会因为"多个唯一键同时冲突"而行为异常？
第三个问题几乎是所有疑难杂症的根源，后文会重点展开。先记住结论：触发范围 = 主键 + 所有唯一索引，不是只有主键。
2.2 affected rows 的三种含义，版本不同结果不同
很多人在排查问题时都会看一眼"受影响行数"。这个值在 upsert 场景里有三种可能：1、0、2。对应关系如下：
| affected rows 值 | 实际执行结果 | 说明 |
|---|---|---|
| 1 | 新插入了一行 | 无任何冲突，正常 INSERT |
| 0 | 已存在且内容未变化 | 触发 UPDATE，但新旧值相同，MySQL 做了"假装没更新"的优化 |
| 2 | 已存在且内容被更新 | 触发 UPDATE，且确实改了数据（某些版本里 2 表示一行插入 + 一行更新） |
注意最后一行，affected rows = 2 可不是"插入了两行"，而是插入了零行 + 更新了一行，只不过 MySQL 在计数时把"尝试插入"和"实际更新"都算进去了。这个语义在 5.x 老版本是稳定为 2，但在 MySQL 8.0 里如果你更新的内容和原值完全一样，返回的是 0。
这个差异直接影响业务代码怎么判断"到底插入了还是更新了"。如果你在应用层用 int rows = executeUpdate(sql) 去区分，1 代表 insert、2 代表 update，那到了 8.0 环境很可能会把"值没变的更新"误判成插入失败。
我见过一个真实 case：数据同步任务里，每次从上游拉取用户资料，如果信息没变化就跳过，靠 affected rows 判断。从 5.7 升 8.0 之后，任务大量误报"插入失败"，排查半天发现就是 value 完全一致导致 rows=0，和"插入失败"的表现一模一样。这个坑等会还会专门讲。
2.3 复合唯一索引的边界条件
复合唯一索引（也叫联合唯一索引）是另一个容易理解偏差的地方。比如订单表里定义了：
sql复制CREATE TABLE order_item (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_id BIGINT NOT NULL,
item_no VARCHAR(32) NOT NULL,
quantity INT DEFAULT 1,
UNIQUE KEY uk_order_item (order_id, item_no)
);
这里的唯一性约束是 (order_id, item_no) 组合，意味着同一订单下商品编号不能重复，但不同订单之间可以出现相同 item_no。用 ON DUPLICATE KEY UPDATE 时，只有整组唯一键值都重复才会触发更新：
sql复制INSERT INTO order_item (order_id, item_no, quantity)
VALUES (1001, 'SKU-A', 5)
ON DUPLICATE KEY UPDATE quantity = quantity + 1;
第二次执行同样的 order_id + item_no，命中 uk_order_item，将 quantity 从 5 更新为 6。但如果订单号从 1001 变成 1002，即便 item_no 还是 'SKU-A'，也不会触发任何冲突，直接插入新行——因为组合键的完整值并不重复。
这个逻辑看上去很符合直觉，但实际使用时容易栽在一个细节上：如果复合唯一索引中某个字段允许为 NULL，MySQL 的唯一性判断会"放水"。 在 MySQL 中，唯一索引允许存在多个 NULL 值，因为 NULL = NULL 的最终结果是 NULL（未知），不是真（TRUE），所以不构成冲突。也就是说，两条 (order_id = 1001, item_no = NULL) 的记录可以同时存在，ON DUPLICATE KEY UPDATE 根本不会被触发。
这在业务上很要命。比如先用手机号+渠道的组合唯一键做防重，渠道字段偶尔为空，结果空渠道的用户被反复插入。排查时如果不知道"NULL 唯一索引不冲突"这个特性，光看表结构完全找不到原因。
3. 多唯一键同时存在的"三体问题"，最容易翻车的区域
3.1 多个唯一键冲突时，竟会更新多行数据
现在进入本文的核心暗区：当一张表同时拥有多个不同的唯一索引时，ON DUPLICATE KEY UPDATE 的行为会变得非常诡异。
举个例子，先建一张表：
sql复制CREATE TABLE account (
id INT PRIMARY KEY AUTO_INCREMENT,
email VARCHAR(64) NOT NULL,
phone VARCHAR(20) NOT NULL,
nickname VARCHAR(32),
UNIQUE KEY uk_email (email),
UNIQUE KEY uk_phone (phone)
);
表里已有两行数据：
| id | phone | nickname | |
|---|---|---|---|
| 1 | a@test.com | 13800000001 | 用户A |
| 2 | b@test.com | 13800000002 | 用户B |
现在执行一条插入语句，email 撞了第一行的唯一键，phone 撞了第二行的唯一键：
sql复制INSERT INTO account (email, phone, nickname)
VALUES ('a@test.com', '13800000002', '新用户')
ON DUPLICATE KEY UPDATE nickname = '被更新';
你猜会发生什么？
常规思维是"冲突了，选一行更新，或者直接报错"。但 MySQL 的实际行为是：它会更新所有冲突的行。上面这条 SQL，id=1 的行因为 email 冲突被更新，id=2 的行因为 phone 冲突也被更新，最后两张表的 nickname 都变成了'被更新'。
也就是说，一条插入语句可能通过唯一键匹配到多行，并逐一执行更新。如果业务代码里认为"反正一行最多匹配一个唯一键"，那这个行为就会造成大面积误更新。
我在生产环境遇到过一次统计事故。业务表同时有业务单号唯一键和全局流水号唯一键，一个补单任务用了 ON DUPLICATE KEY UPDATE，因为构造数据时单号和流水号来源不一致，恰好分别撞上了两行不同的历史记录，结果一次性把两条历史单据的状态都改了，而且没有任何报错。数据修复花了一整天。
3.2 主键冲突优先，还是唯一索引冲突优先？
MySQL 的官方文档并没有承诺一个明确的优先级，但在实际执行计划中，InnoDB 引擎会先检查主键冲突，再检查唯一索引冲突。如果主键冲突，直接走 update 分支；如果没有主键冲突但有唯一索引冲突，也会走 update 分支。
这个"顺序"在大多数情况下感知不到，因为结果都是进入 update。但一旦涉及"多行冲突"，顺序就变得重要了。上面那个例子如果插入语句里主键也和某行冲突了，那主键命中的这一行会先被锁定并更新，其他唯一索引命中的行也会尝试被更新。整个过程涉及的锁范围比想象中更大，这是后面讲死锁时的关键伏笔。
3.3 多行冲突时的影响范围，简单场景实测
为了验证多行冲突行为，我用 MySQL 8.0.32 做过一个简单实测。还是用 account 表，先插入两条基础数据，然后执行上面那条冲突两条唯一键的 insert，通过 ROW_COUNT() 和查询结果确认最终状态。
执行前：
| id | phone | nickname | |
|---|---|---|---|
| 1 | a@test.com | 13800000001 | 用户A |
| 2 | b@test.com | 13800000002 | 用户B |
执行：
sql复制INSERT INTO account (email, phone, nickname)
VALUES ('a@test.com', '13800000002', '新用户')
ON DUPLICATE KEY UPDATE nickname = '被更新';
执行后：
| id | phone | nickname | |
|---|---|---|---|
| 1 | a@test.com | 13800000001 | 被更新 |
| 2 | b@test.com | 13800000002 | 被更新 |
注意，id=1 行的唯一键冲突来自 email，id=2 行的冲突来自 phone，两边都被更新了。ROW_COUNT() 返回 2。
如果业务预期是"只更新一行"，这里的语义就完全不符合预期。这是这个语法最重要的行为边界，用之前必须想清楚表上有几个唯一键。
4. 业务落地：怎么把它用得又稳又准
4.1 幂等写入的正确姿势：单唯一键场景
单唯一键场景是最简单的，也是 ON DUPLICATE KEY UPDATE 最理想的使用环境。比如用户表只按手机号防重：
sql复制INSERT INTO user (phone, nickname, status)
VALUES ('13800138000', '用户C', 1)
ON DUPLICATE KEY UPDATE
nickname = VALUES(nickname),
status = VALUES(status);
这套写法在绝大多数业务里够用了。要注意的是，MySQL 8.0.20 之后官方推荐用 AS 别名语法替代 VALUES() 函数，因为后者在新版本里已被标记为 deprecated：
sql复制INSERT INTO user (phone, nickname, status)
VALUES ('13800138000', '用户C', 1) AS new_user
ON DUPLICATE KEY UPDATE
nickname = new_user.nickname,
status = new_user.status;
这个新语法的好处是更直观，能避免 VALUES() 在某些复杂表达式下的歧义。不过老项目里大量 VALUES() 写法也不会立刻失效，8.0 里还能跑，只是会有 deprecation 警告。如果公司有严格的异常监控，把告警阈值调一下，或者直接在新代码里用新语法，省得以后被警告刷屏。
一个很容易被忽略的小点是：UPDATE 分支里如果修改了唯一键本身，也会引发连锁反应。比如：
sql复制INSERT INTO user (phone, nickname)
VALUES ('13800138000', '用户C')
ON DUPLICATE KEY UPDATE phone = '13900139000';
第一次插入 phone=13800138000，第二次执行时原本该触发冲突更新，但更新分支把 phone 改成了 13900139000，相当于把唯一键迁移了。如果新 phone 值恰好也和其他行的唯一键冲突，这个 SQL 会直接报死锁错误，因为 MySQL 需要检查更新后的唯一性约束。业务上要改唯一键值的情况，务必先把唯一索引的规则理清楚，否则很容易自己把自己锁死。
4.2 老数据重复了，怎么安全加唯一索引
很多实际业务不是从一开始就设计了唯一索引，而是跑了一段时间后数据已经有了重复，这时候想把唯一索引加上去，直接执行 DDL 会报错。比如：
sql复制ALTER TABLE user ADD UNIQUE KEY uk_phone (phone);
如果 user 表里存在两条 phone 相同的记录，这行语句会直接失败并提示 Duplicate entry '13800138000' for key 'uk_phone'。
正确的处理思路是"先治理，再建索引"，大致分三步走：
第一步：找出重复数据
sql复制SELECT phone, COUNT(*) AS cnt
FROM user
GROUP BY phone
HAVING cnt > 1;
第二步：确定保留策略并清理
常见策略包括：保留最小 id、最后更新时间最新的一条，其余行做逻辑删除或合并。比如保留最小 id：
sql复制DELETE u1 FROM user u1
INNER JOIN user u2
ON u1.phone = u2.phone
AND u1.id > u2.id;
这个语句会把每个重复组里 id 较大的行删掉，保留最小 id 那一行。
第三步：再执行 ALTER TABLE 添加唯一索引
清理完之后 DDL 就能顺利通过了。在生产大表上执行 ALTER TABLE 前，最好用 pt-osc 或者 gh-ost 这类在线改表工具，避免长时间锁表影响线上读写。 这个坑我踩过，几千万行的表直接 ALTER，把业务的写请求卡了接近十分钟，差点酿成事故。
4.3 批量同步/回填脚本中的实战写法
数据回填是 ON DUPLICATE KEY UPDATE 的典型应用场景。比如从旧系统同步用户数据到新表，每天跑一次增量任务：
sql复制-- 源表：old_user
-- 目标表：new_user
INSERT INTO new_user (user_id, phone, nickname, updated_at)
SELECT user_id, phone, nickname, NOW()
FROM old_user
WHERE updated_at > :last_sync_time
ON DUPLICATE KEY UPDATE
phone = VALUES(phone),
nickname = VALUES(nickname),
updated_at = VALUES(updated_at);
这里的 INSERT ... SELECT 组合非常实用，它允许直接把查询结果作为插入数据源。配合 ON DUPLICATE KEY UPDATE 后，同步任务天然具备"有则更新、无则插入"的能力。
但批量场景有两个雷区，我必须单独拿出来讲：
雷区一：数据源本身包含重复键
如果 SELECT 出来的结果集里，在目标表的唯一键上本身就存在重复值（哪怕是在源表里不重复，被 SELECT 转换后也可能重复），MySQL 执行时会不确定选哪一行怎么办。实测中当同一批次里出现同一个唯一键的多行时，MySQL 会按顺序处理，后处理的行会触发更新、覆盖先处理的行。这不会报错，但结果可能不符合预期。所以在同步前务必确认源数据在目标唯一键上也是唯一的。
雷区二：大事务锁范围爆炸
一次同步几百万行时，如果全部包在一个隐式事务里，InnoDB 会锁住大量索引记录和间隙，锁竞争和死锁概率都会急剧上升。建议分批执行，比如每 5000 行一个事务提交，SQL 层面可以用：
sql复制INSERT INTO new_user (...) SELECT ... WHERE id BETWEEN 1 AND 5000
ON DUPLICATE KEY UPDATE ...;
配合循环调用来分段执行。这里非常重要：不要在一条 INSERT ... SELECT 里处理全量数据，否则一旦中途失败回滚，回滚代价极高。
5. 版本差异与替代方案：为什么别人一用就报错
5.1 5.7 与 8.0 的 affected rows 语义差异
前面提到过 MySQL 8.0 对 affected rows 的返回值做了优化。具体来说，在 5.7 及更早版本中，只要走到 update 分支，affected rows 几乎都返回 2（插入动作加更新动作）；而在 8.0.0 以后（尤其是 8.0.2x 之后），如果 update 分支设置的新值和原值完全一致，affected rows 返回 0。
这个变化本身是为了减少客户端无效的数据变更感知，但对依赖 affected rows 做业务判断的老代码是破坏性的。看看这个典型误判：
java复制int rows = jdbcTemplate.update(
"INSERT INTO t ... ON DUPLICATE KEY UPDATE num = num"
);
if (rows == 1) {
// 认为是插入
} else if (rows == 2) {
// 认为是更新
}
同一段代码，5.7 下执行更新时 rows=2，8.0 下因为更新内容没变化 rows=0。如果后续逻辑在 rows=0 时抛"插入失败"异常，升级数据库版本后任务会成片报错。
正确做法是不要依赖 affected rows 的具体数值判断插入还是更新，而是先查再写，或者用其他业务字段判断。如果一定要判断，可以先把语句改成一定能产生变化的形式，比如把 updated_at 强制更新为当前时间，保证行值变化，从而让 rows 至少为 1 或 2。
5.2 PostgreSQL 的 ON CONFLICT 写法对照
标题里提到了 MySQL，但很多团队多库并存。PostgreSQL 提供了更标准的 upsert 语法，即 INSERT ... ON CONFLICT ... DO UPDATE。两者的核心差异在于，PG 的 ON CONFLICT 可以显式指定冲突目标：
sql复制INSERT INTO account (email, phone, nickname)
VALUES ('a@test.com', '13800000002', '新用户')
ON CONFLICT (email) DO UPDATE
SET nickname = EXCLUDED.nickname;
这里的 ON CONFLICT (email) 明确指定"只在 email 冲突时走更新", 不会出现 MySQL 那种多个唯一键撞一行或多行时模糊处理的问题。如果多个唯一键同时冲突，PG 可以直接报 cardinality_violation，提示"ON CONFLICT DO UPDATE 命令无法影响多行"。
对于已经深度使用 MySQL 的团队来说，这个区别值得在建表阶段就提前规划：如果一张表将来可能同时存在多个唯一键，且业务对"哪个键触发更新"有明确预期，换到 PG 或者其他支持 ON CONFLICT 指定冲突目标的数据库会更安全。
5.3 INSERT IGNORE 和 REPLACE INTO，到底选谁
实际开发中还经常遇到另外两种防重手段，简单对比一下：
| 方案 | 冲突行为 | 是否删除原行 | 是否更新原行 | 适用场景 |
|---|---|---|---|---|
| INSERT IGNORE | 忽略冲突，静默丢弃 | 否 | 否 | 只插入不更新，比如日志流水 |
| REPLACE INTO | 先删旧行，再插新行 | 是 | 等效于删除+插入 | 全字段覆盖，不关心自增主键变化 |
| ON DUPLICATE KEY UPDATE | 走 update 分支更新 | 否 | 是 | 需要保留主键/原行数据的 upsert |
REPLACE INTO 很容易被误用。因为它背后是"删除原行 + 插入新行"，会导致自增主键变化、外键关联断裂、甚至触发器重复执行。如果是大表，删除插入的代价也比 update 高得多。绝大多数需要用 upsert 的场景，ON DUPLICATE KEY UPDATE 都是更合适的选择。
INSERT IGNORE 则最适合那些"重复了就忽略，不需要更新"的场景，比如埋点日志、去重采集。它和 ON DUPLICATE KEY UPDATE 的冲突判断逻辑是一样的（都会看主键和所有唯一索引），只是冲突后的动作不同：一个是忽略，一个是更新。
6. 生产环境排查实录与个人经验总结
6.1 MyBatis-Plus 的 insert 没报错但数据没写进去，是怎么回事
相关热搜词里有个非常典型的问题："mybatis plus insert 数据没有写成功，但也没有报错"。这个问题如果配合 ON DUPLICATE KEY UPDATE 使用，大概率是 affected rows 语义搞混了。
MyBatis-Plus 的默认 insert 方法会生成普通 INSERT，如果库里已有相同唯一键，它不会自动帮你走 upsert 分支。你需要使用 insertOrUpdate 或自定义 SQL。但很多人注释 @TableId 用错了主键类型，或者实体类里没有正确声明唯一索引对应的字段，导致框架生成的 INSERT 根本没带 ON DUPLICATE KEY UPDATE 子句，冲突时 MySQL 直接忽略或报错。
还有一种情况：MySQL 的 sql_mode 里有 STRICT_TRANS_TABLES，插入数据超出字段长度时，JDBC 驱动可能把错误吞了，事务又刚好配置成"忽略异常继续提交"，最终数据没写进去、应用也不报错。排查这类问题时，第一步先打开 MySQL 的 general_log，看应用实际发出的 SQL 是什么。 很多时候你以为跑了 upsert，实际跑的是普通 INSERT。
我之前帮人排查过一个类似 case，最后发现是 MyBatis-Plus 的 FieldStrategy 默认策略是 NOT_NULL，实体里某个非空字段值为 null，生成 SQL 时直接被忽略掉，导致插入数据不完整，而 ON DUPLICATE KEY UPDATE 也没有任何更新效果。把字段策略改成 FieldStrategy.ALWAYS 或者补全字段值就好了。
6.2 死锁问题：多行冲突 + 并发写入是重灾区
死锁是 ON DUPLICATE KEY UPDATE 在生产环境最常出现的故障之一。触发机制其实很清晰：InnoDB 在执行 upsert 时，会对命中的唯一索引加锁，锁的顺序由索引检查顺序决定。如果有多个唯一索引，不同连接插入不同行时，可能以不同顺序锁同一批索引记录，从而形成死锁。
举个最简单的例子，表里有 uk_email 和 uk_phone，两个事务同时执行：
事务 A 插入 (a@test.com, 13900000001)，先锁 uk_email 上 a@test.com 的位置、再锁 uk_phone 上 13900000001 的位置；事务 B 插入 (b@test.com, 13900000001)，先锁 uk_phone 上 13900000001 的位置、再锁 uk_email 上 b@test.com 的位置。两个事务互相等对方的锁，死锁。
缓解手段主要有几个方向：
- 减少唯一索引数量：能用单唯一键尽量不加第二个唯一键，这是最根本的解法。很多业务其实可以接受先查后插。
- 统一加锁顺序：在应用层对数据按某个字段排序后再执行 upsert，尽量减少交叉锁。
- 批量操作控制并发度：同步任务开启多线程时，给并发线程数设上限。
- 设置合理的 innodb_lock_wait_timeout：让死锁快速暴露，而不是无限等待，默认 50 秒太长，生产环境我一般调到 5 秒。
死锁发生后，InnoDB 会自动回滚其中一个事务，业务层一定要捕获死锁异常并做重试。很多团队只做了超时异常捕获，没做死锁重试，结果一遇到并发 upsert 就批量失败。
6.3 触发器与 DELAYED 特殊情况的注意事项
如果表上有触发器（BEFORE INSERT / AFTER UPDATE），ON DUPLICATE KEY UPDATE 的语义会再复杂一层。因为一条语句既可能有 INSERT 动作，也可能有 UPDATE 动作，对应的触发器都会被触发。
举个例子，BEFORE INSERT 触发器里可能给某字段赋默认值，INSERT 冲突后走到 UPDATE 分支时，BEFORE INSERT 触发器已经执行过了，但 UPDATE 分支不会回放这个赋值。所以 UPDATE 分支拿到的值可能是触发器赋值前的原始值，这会造成数据不一致。
如果启用了 INSERT DELAYED（MySQL 5.6 以后基本废弃，8.0 里语法已移除），情况还要复杂。不过我建议所有读者都不用纠结 DELAYED，直接避开。这个特性要延迟到表空闲时插入，和 ON DUPLICATE KEY UPDATE 的实时性要求天然冲突，生产环境里几乎找不到正当理由去用它。
6.4 最后再分享一个小技巧：如何快速验证一条 upsert 会不会误更新
准备上线任何一条带 ON DUPLICATE KEY UPDATE 的 SQL 前，我建议先做两个检查：
第一，用 SHOW CREATE TABLE 看全所有唯一索引，确认业务预期的冲突键在不在里面。很多表表面看着有唯一索引，实际可能是复合索引，顺序不对就不会触发。
sql复制SHOW CREATE TABLE account;
第二，在测试库造一组"多行冲突"数据，直接执行这条 SQL，观察 ROW_COUNT() 和最终数据。如果发现更新了多行，立刻停下来重新审视业务逻辑。不要在生产环境做这个实验，因为多行冲突的后果真的难以预料。
这两个检查花不了十分钟，但能帮你避开"上线后才发现更新错一片"的灾难。
说实话，ON DUPLICATE KEY UPDATE 在我看来是 MySQL 里最"短小精悍但暗藏汹涌"的语法之一。它能帮你用一条语句完成 insert-or-update，代码简洁、性能可观，但前提是你对表上的每一个唯一键都了如指掌。非主键唯一字段正是这张"暗牌"——它在绝大多数场景下会按你预期工作，可一旦多唯一键或多行冲突同时出现，行为就超出了很多人的认知范围。
我个人的使用习惯是：能预先在表设计阶段明确唯一键的，绝不在代码里靠 upsert 兜底；必须用 upsert 的，优先保证数据源唯一；涉及多唯一键时，宁可在应用层先 SELECT 一次，也不依赖这个语法去处理复杂冲突。 每次上线前问自己一句"如果这条语句同时撞了 index A 和 index B，会不会出事"，带着这个问题去审查，基本能避开绝大多数坑。