MySQL中UPDATE JOIN重复更新最常见表现是一条目标记录被多条源记录匹配，MySQL默认取JOIN结果第一行赋值，不报错但结果不可控。
MySQL中UPDATE JOIN重复更新的典型表现
最常见的是：一条目标记录被多条源记录匹配，MySQL默认取JOIN结果的第一行赋值，不报错但结果不可控。比如users表某用户关联了3条orders，其中2条是status = 'shipped'、1条是'cancelled'，执行UPDATE users u JOIN orders o ON u.id = o.user_id SET u.last_shipped_at = o.created_at时，你无法预测最终写入的是哪条订单的时间。
- ON条件没加唯一性约束（如漏掉
o.is_main = 1或o.status IN ('shipped', 'delivered')） - 源表本身有重复键（如
orders里同一user_id有多条未去重的测试数据） - JOIN后没用
WHERE进一步过滤，仅靠ON做关联
PostgreSQL和SQL Server中FROM更新的重复风险
PostgreSQL在UPDATE ... FROM中遇到多行匹配时，会随机选一行更新；SQL Server则直接报错Subquery returned more than one value（如果用子查询），但用FROM时行为类似PG——不报错、不提示、结果不确定。
关键区别在于：PostgreSQL的FROM子句不支持LIMIT或ROW_NUMBER()直接控制取哪一行，必须提前物化。
- 别写
UPDATE t1 SET x = t2.val FROM t2 WHERE t1.id = t2.t1_id——当t2对同一个t1.id有多条记录时，就危险 - 正确做法是先用CTE或子查询去重：
FROM (SELECT DISTINCT ON (t1_id) t1_id, val FROM t2) t2 - SQL Server可用
TOP (1)子查询，但性能差；更稳的是ROW_NUMBER() OVER (PARTITION BY t1_id ORDER BY updated_at DESC)+ CTE
Oracle MERGE INTO如何防重复匹配
MERGE INTO本身不允许多对一匹配成功，一旦源数据对同一目标键出现重复，会立刻报错ORA-30926: unable to get a stable set of rows。这不是bug，是设计保护机制。
所以它天然比其他数据库更“安全”，但代价是你必须主动处理重复：
- 在
USING子查询里强制去重，例如：(SELECT user_id, MAX(created_at) created_at FROM orders GROUP BY user_id) - 用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)+WHERE rn = 1 - 避免在
ON里写业务条件（如status = 'active'），否则可能让本该去重的行被过滤掉，反而绕过校验
通用兜底策略：先查再确认，再更新
无论用哪种语法，只要关联逻辑稍复杂，就该把UPDATE前的验证步骤当成必选项。不是“可选优化”，而是防止线上事故的最小成本动作。
- 把UPDATE语句里的
JOIN或FROM部分原样复制，改成SELECT COUNT(*)或SELECT DISTINCT target_id，确认结果集行数是否等于预期更新行数 - 特别注意
WHERE条件是否同时作用于主表和关联表——比如u.is_vip = 0 AND o.status = 'shipped'，漏掉任一都可能放大更新范围 - 大表更新前加
LIMIT 100（MySQL需改写为子查询+LIMIT）试跑，观察日志和锁表现
重复更新往往不报错，只悄悄写错数据。最麻烦的不是修复SQL，而是发现哪几万条记录被误写了——这种问题通常在下游报表异常后才暴露。
