MySQL的UPDATE JOIN语法必须将被更新的表置于UPDATE后首位，JOIN写在UPDATE后、SET前，且需明确ON条件与WHERE过滤；PostgreSQL和SQL Server则分别采用UPDATE...FROM结构，语义和细节差异显著。
UPDATE JOIN 是 MySQL 唯一原生支持的多表就地更新语法，能避免查—改两步操作，但写错顺序或条件会直接误更新，不是“能用就行”，而是“必须写对”。
MySQL 的 UPDATE JOIN 语法必须主表在前
MySQL 不允许 UPDATE t2 JOIN t1 ON ... SET t2.x = t1.y 这种写法——哪怕逻辑上 t2 才是目标。它强制要求被更新的表（主表）必须紧跟在 UPDATE 关键字后面，且只能有一个。
-
UPDATE后第一个表名就是实际被修改数据的表，其余都是“只读”参与关联的表 - JOIN 顺序不重要，但 ON 条件里的字段归属必须明确：比如
ON orders.user_id = users.id，不能写成ON orders.id = users.user_id（字段名错配、主从颠倒） - 如果 ON 条件没约束唯一性（如漏掉
users.is_deleted = 0），MySQL 默认取匹配结果的第一行赋值，不会报错，但结果不可控
正确示例：
UPDATE orders o JOIN users u ON o.user_id = u.id SET o.user_name = u.name WHERE u.status = 'active';
PostgreSQL 和 SQL Server 要用 FROM，不是 JOIN
PostgreSQL 完全不认 UPDATE ... JOIN，SQL Server 也不支持。它们统一用 UPDATE ... FROM 结构，但语义和细节差异大。
- PostgreSQL 的
FROM后可跟表或子查询，但ON条件必须挪到WHERE子句里，例如：WHERE o.user_id = u.id AND u.is_verified - SQL Server 允许在
FROM中写INNER JOIN，但更新目标仍只能是UPDATE后那个表，别名不能省略 - 容易漏掉
WHERE中的关联约束——一旦忘记写u.id = o.user_id，就会把所有o.user_name设成同一个u.name值
PostgreSQL 示例：
UPDATE orders o SET user_name = u.name FROM users u WHERE o.user_id = u.id AND u.is_verified;
子查询方式通用但性能敏感，慎用于大表
SET field = (SELECT ...) 在 MySQL、PostgreSQL、Oracle、SQL Server 全平台可用，但每行都会触发一次子查询，没有 JOIN 那种一次扫描复用的能力。
- 子查询必须返回 0 或 1 行，否则 MySQL 报
Subquery returns more than 1 row，PostgreSQL 报more than one row returned - 即使你“知道”只有一条，也得显式加
LIMIT 1或补WHERE，否则数据库不优化、不走索引、不短路 - 若子查询涉及未建索引的关联字段（如
WHERE id = orders.user_id但users(id)没索引），30 万行更新可能从 200ms 拖到 40s+
安全写法：
UPDATE orders SET user_name = ( SELECT name FROM users WHERE id = orders.user_id AND is_verified LIMIT 1 ) WHERE EXISTS ( SELECT 1 FROM users WHERE id = orders.user_id AND is_verified );
关联失败时字段变 NULL？这是默认行为，得自己兜底
无论是 UPDATE JOIN 还是 UPDATE FROM，只要关联不上，对应字段就会被设为 NULL（除非你用 LEFT JOIN + COALESCE 显式保留原值）。
- 想“只更新有匹配的行，其余不动”，就得加
WHERE筛选，或者用EXISTS子查询兜底 - 想“没匹配就清空”，反而不用额外处理——这是默认行为，但容易被当成 bug
- 线上执行前务必先用
SELECT模拟验证：SELECT o.id, o.user_name, u.name FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.id IS NULL看看哪些会变 NULL
真正难的不是语法，是确认 ON 条件是否真能一对一命中；很多“更新后数据不对”的问题，根源都在这里。
