在 MySQL 里，UPDATE ... JOIN 只有在关联条件严格一对一时才安全；一旦左表一行匹配右表多行，同一行可能被多次命中并被最后一次结果静默覆盖。

为什么同一行会被多次命中

根因是 JOIN 条件不唯一。常见情况：

• 关联字段没有唯一约束，如临时表 order_id 重复。
• JOIN 条件漏掉状态、时间范围、业务分区等过滤。
• 一对多关系直接参与更新。

怎么快速判断 JOIN 是否已失去唯一性

先看执行计划

EXPLAIN FORMAT=TREE UPDATE ...

重点看 Using join buffer，以及 rows 是否明显大于左表待更新行数。

再做重复命中检查

SELECT COUNT(*) FROM t1 JOIN t2 ON ... GROUP BY t1.id HAVING COUNT(*) > 1

只要有结果，这次 JOIN 就不是一对一，直接更新有风险。

把 JOIN 约束成严格一对一

• 临时表关联字段如 order_id 建 PRIMARY KEY 或 UNIQUE KEY。
• 目标表被关联字段如 orders.id 必须有索引，且两边类型一致，如 INT 对 INT，不要 BIGINT 对 INT。
• 不要直接用 CREATE TEMPORARY TABLE AS SELECT，它不会继承主键。

如果业务天然是一对多，先预聚合右表，再参与更新：

SELECT order_id, MAX(status) AS status
FROM order_items
GROUP BY order_id

什么时候应该改用 EXISTS

如果只是判断“是否存在匹配记录”，不需要从右表取值，EXISTS 通常比 JOIN 更安全。

UPDATE orders SET status = 'processed' WHERE id IN (SELECT order_id FROM tmp_updates)

这能用，但要求 tmp_updates.order_id 有索引。

UPDATE orders o SET status = 'processed' WHERE EXISTS (SELECT 1 FROM tmp_updates t WHERE t.order_id = o.id)

EXISTS 不会因右表重复记录放大更新次数，适合外部导入、批量同步、临时修复等不可完全信任的数据源。

上线前必须做的三步校验

1. 先跑等价查询，确认没有重复命中：

SELECT o.id, COUNT(*) FROM orders o JOIN tmp_updates t ON o.id = t.order_id GROUP BY o.id HAVING COUNT(*) > 1

1. 执行后核对 Rows matched 是否等于预期更新行数。
2. 先小批量试跑，例如加 LIMIT 100，再观察日志和监控。