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，但最终只有其中一个的更新生效（另一个被锁住后覆盖），而应用层无法感知这种覆盖顺序。
