跨表更新这种操作，看着简单，一换数据库就翻车，这大概是搞 SQL 最头疼的破事之一。先说说我见过最多的情况：明明数据源表都准备好了，目标表字段结构也对，结果一句 UPDATE 下去，不是报错就是更新了不该更新的行，甚至还会把整张表给覆盖掉。核心原因其实就两个——语法写错了，或者 JOIN 关系没管好。不同数据库在这件事上的规矩各不相同，弄不清那点区别，事故就差一个回车。
UPDATE ... FROM 语法在 PostgreSQL 和 SQL Server 中怎么写
PostgreSQL 和 SQL Server 都原生支持 UPDATE ... FROM 这种写法，可以直接用源表的字段去更新目标表，不需要折腾子查询或临时表。但说“支持”不代表写法一样，中间有很关键的区别，一不小心就会栽在 JOIN 条件或别名上面。
最常见的报错之一，PostgreSQL 会给你扔一句 ERROR: missing FROM-clause entry for table "t2"；而在 SQL Server 这边，则可能报 The multi-part identifier "t2.name" could not be bound。本质原因就是别名没对齐，或者 JOIN 写法不合规。
- PostgreSQL 有个死规矩：必须显式写
FROM再加上JOIN，而且目标表不能在FROM子句里再次出现；别名则在UPDATE后声明，FROM里另起一个别名也行，但得保持一致 - SQL Server 的写法看起来更随意，允许
UPDATE t1 SET ... FROM t1 JOIN t2 ...，但目标表必须带别名，而且所有字段引用都必须带上这个别名前缀 - 还有一个共同的坑：JOIN 条件必须绝对精确，否则很容易出现一对多，结果要么更新了多行，要么一张表只剩零行
以 PostgreSQL 为例，标准写法是这样的：
UPDATE users t1SET email = t2.email, status = t2.statusFROM new_data t2WHERE t1.id = t2.user_id;
MySQL 怎么实现类似效果（没有 UPDATE ... FROM）
MySQL 这边更绝，它压根不支持标准 UPDATE ... FROM 语法，必须用 JOIN 或子查询来绕路。直观来说，用 JOIN 效率更高，但也更容易翻车——字段引用规则和别名位置害哭了不少人。
常有人报错 Unknown column 't2.email' in 'field list'，其实是因为 MySQL 有一条铁律：被更新的目标表必须最先出现在 UPDATE 子句中，而且 JOIN 的别名必须在两边完全一致。
- 正确的姿势：
UPDATE t1 JOIN t2 ON ... SET t1.col = t2.col，其中 t1 是目标表，必须先写 - 如果顺序搞反了，写成
UPDATE t2 JOIN t1 ...，那更新的就是源表了 - 关联字段如果重名（比如两表都有 id），加表别名是必选项，不然直接报错
- 子查询虽然也能做，但在 MySQL 里压力很大——同一张表在子查询和外层 UPDATE 间有加锁冲突，动不动就报
You can't specify target table 't1' for update in FROM clause。
具体写法：
UPDATE users t1JOIN new_data t2 ON t1.id = t2.user_idSET t1.email = t2.email, t1.status = t2.status;
WHERE 条件漏写或太宽泛导致误覆盖
这年头，因为漏写 WHERE 来删库跑路的段子还少吗？表面是少写个条件，实则背后风险爆棚。不管用的是 PostgreSQL 还是 MySQL，只要 WHERE 条件太松，或者关联字段只有模糊匹配，整张表就可能被批量改掉，而且不可逆。
- 动手之前先确认关联字段有索引，否则 UPDATE 会全表扫描，锁表时间长得让人心慌
- 建议先用
SELECT模拟一遍：把UPDATE改成SELECT *，把SET换成查看目标字段，先验证匹配行数是否符合预期 - 生产环境里还有个死规矩：强制加
LIMIT（MySQL 专属），或者用事务把 UPDATE 包起来，更新后立刻SELECT核对几条数据 - 源表可能有空值的场景，
SET t1.col = t2.col一跑，目标字段很可能直接变 NULL。这种情况必须提前加COALESCE(t2.col, t1.col)来保护原值
Oracle 和 SQLite 的替代方案
最后聊两个不怎么爽的。Oracle 没有 UPDATE ... FROM，得用 MERGE INTO 这种高阶语法来绕；SQLite 更激进，只支持单表 UPDATE，跨表更新全靠子查询或分步处理。这两者写起来都比较绕，而且安全性更难控制。
- Oracle 的
MERGE INTO必须写全WHEN MATCHED THEN UPDATE分支，而且ON条件不支持复杂表达式，隐式类型转换不到位就直接失败 - SQLite 如果非要跨表更新，只能写成
UPDATE t1 SET col = (SELECT col FROM t2 WHERE t2.id = t1.id)这种子查询形式。但子查询返回多行会报错，只能硬性确保关联唯一 - SQLite 还没有
UPDATE ... LIMIT这种限制行数的手段，风险直接翻倍
真正麻烦的其实不是语法本身，是不同数据库对“关联唯一性”的校验松紧差太多——有些允许一对多 JOIN 后随机选一行更新，有些直接报错。上线前必须在自己用的数据库里，拿真实数据分布测一遍。
