ON DUPLICATE KEY UPDATE仅在主键或任意唯一索引冲突时触发更新,否则退化为普通插入;必须存在PRIMARY KEY或UNIQUE KEY约束,缺失则永不更新,且多唯一键共存时更新行为不可控。

必须有主键或唯一索引,否则它根本不会触发更新,只会无脑插入。
ON DUPLICATE KEY UPDATE 触发条件只认主键和 UNIQUE 约束
MySQL 不会因为你“觉得数据重复”就执行更新——它只检查是否违反了 PRIMARY KEY 或任意一个 UNIQUE KEY。哪怕两行数据其余字段完全一样,只要主键或唯一索引值不重,就会当作新记录插入。
常见错误现象:
- 表没建唯一约束,语句始终走插入分支,
affected_rows永远是 1 - 误以为 email 字段有索引就能靠它去重,结果发现 email 列没加
UNIQUE,语法无效 - 多个唯一键共存时(比如
user_id和email都是 UNIQUE),只要任一冲突就触发更新,但UPDATE只作用于一行(LIMIT 1行为),具体更新哪条由索引顺序和内部匹配逻辑决定,不可控
使用场景:适合明确知道用哪个字段做“存在性判断”的业务,比如用 user_id 同步用户资料、用 sku 同步商品库存、用 date + metric_name 组合唯一索引写入日志聚合值。
VALUES() 函数是批量合并的关键
在 ON DUPLICATE KEY UPDATE 的更新部分,VALUES(column_name) 会返回当前这条 INSERT 语句中该列的原始值。这在批量操作中尤其重要,否则你无法区分“这次要插入的值”和“数据库里原来的值”。
示例(同步临时表):
INSERT INTO users (id, name, email, updated_at) SELECT id, name, email, NOW() FROM users_temp ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email), updated_at = VALUES(updated_at);
注意点:
- 不能写
name = name或name = 'xxx',那样会覆盖成固定值或不变值 - 如果想做累加(如积分+5),得写
score = score + 5,不能依赖VALUES() -
VALUES()只在ON DUPLICATE KEY UPDATE子句里有效,在其他地方用会报错
多唯一键共存时行为不稳定,尽量避免
当表上有多个 UNIQUE 索引(比如 username 和 phone 都设了唯一),一条冲突记录可能同时命中多个索引。MySQL 内部会按某种顺序尝试匹配,最终只选中**第一个能定位到的冲突行**执行更新,且仅更新一次。
这意味着:
- 你无法预测是按
username还是phone匹配上的那条记录被更新 - 如果两条不同记录分别在两个唯一键上冲突(比如 A 行 username 重复、B 行 phone 重复),ODKU 只会更新其中一条,另一条被忽略或报错(取决于是否启用 strict mode)
- 官方文档明确建议:“In general, you should try to avoid using an ON DUPLICATE KEY UPDATE clause on tables with multiple unique indexes.”
性能影响:多唯一键会增加唯一性检查开销,尤其在大表上,每个索引都要查一遍。
affected_rows 返回值含义容易误解
这个值不是“影响了多少行”,而是 MySQL 内部对操作类型的编码:
-
1:成功插入新行 -
2:找到冲突行并执行了更新(哪怕新旧值一样) -
0:找到冲突行,但 UPDATE 子句所有赋值都等于原值(即实际未变更);不过若连接时设置了CLIENT_FOUND_ROWS标志,则返回1
所以不能靠 affected_rows == 2 来断定“数据确实变了”,它只说明“执行了更新动作”。真要判断字段是否变更,得在应用层比对或加触发器。
真正容易被忽略的是:它不反映并发下的真实状态。比如两个请求几乎同时触发 ODKU,都看到 affected_rows == 2,但最终只有其中一个的更新生效(另一个被锁住后覆盖),而应用层无法感知这种覆盖顺序。











