SQL标准不支持INNER JOIN直接UPDATE，各数据库语法差异大：MySQL用UPDATE...JOIN但只能更新主表；PostgreSQL用UPDATE...FROM且WHERE必须含连接条件；SQL Server需注意别名绑定陷阱；跨库更新前须用SELECT验证影响行数并加LIMIT/TOP。
SQL 标准不支持直接用 INNER JOIN 写 UPDATE 语句（除少数方言外），所谓“JOIN UPDATE”本质是各数据库的扩展语法，写法、限制和行为差异极大——别照着 MySQL 教程在 PostgreSQL 里硬套，会报错或误更新。
MySQL 中用 JOIN 的 UPDATE 必须用 UPDATE ... JOIN 语法
MySQL 允许 UPDATE t1 JOIN t2 ON ... SET t1.col = t2.col，但有严格限制：
- 不能对被 JOIN 的表（
t2）做 SET 操作，只能更新主表（t1） - 不能在 FROM 子句中再嵌套子查询引用被更新表，否则报错
You can't specify target table 't1' for update in FROM clause - WHERE 条件建议显式写出，避免意外全表更新；例如加
WHERE t1.id IS NOT NULL做兜底
示例：
UPDATE orders o JOIN customers c ON o.customer_id = c.id SET o.status = 'processed' WHERE c.country = 'CN' AND o.status = 'pending';
PostgreSQL 不支持 UPDATE ... JOIN，必须用 FROM 子句
PostgreSQL 的等价写法是 UPDATE ... FROM ... WHERE，但逻辑上不是 JOIN，而是隐式笛卡尔+过滤，容易误写成全量更新：
- FROM 后可跟多表，但 WHERE 必须包含连接条件，否则产生交叉积，UPDATE 行为不可控
- 不能用
USING或ON关键字，连接逻辑全靠 WHERE 中的=表达式承载 - 若目标列名在多个表中存在，必须用别名限定，否则报错
column reference "id" is ambiguous
示例：
UPDATE orders o SET status = 'shipped' FROM customers c WHERE o.customer_id = c.id AND c.vip_level > 3 AND o.status = 'confirmed';
SQL Server 的 UPDATE + FROM 容易踩“别名绑定陷阱”
SQL Server 支持 UPDATE t SET ... FROM t JOIN s ...，但主表 t 在 FROM 中必须用别名，且 UPDATE 后不能重复出现该别名：
- 错误写法：
UPDATE t FROM table1 t JOIN table2 s ...→ 报错The table 't' is ambiguous - 正确写法：UPDATE 后只写表名或别名，FROM 中重新声明别名，连接条件用别名限定
- WHERE 应放在 FROM 之后、SET 之前，否则部分版本会忽略条件
示例：
UPDATE o SET o.amount = o.amount * 1.1 FROM orders o INNER JOIN customers c ON o.customer_id = c.id WHERE c.region = 'EU';
跨库/跨引擎批量更新前必须验证执行计划和影响行数
这类操作没有事务外的预检机制，一旦 WHERE 写错，可能瞬间改掉上万行：
- 先用 SELECT 模拟：把 UPDATE 改成
SELECT COUNT(*)或SELECT TOP 10 *，确保连接结果集大小合理 - 在生产环境务必加 LIMIT/TOP（如 MySQL 加
LIMIT 1000，SQL Server 加TOP 1000），防止锁表太久 - 注意索引：JOIN 字段和 WHERE 字段最好都有索引，否则 UPDATE 可能触发全表扫描+锁升级，导致阻塞
真正麻烦的不是语法，是确认「到底要改哪几行」——很多线上事故，都是因为开发只看了测试数据的 JOIN 结果，没查线上脏数据导致的关联断裂或一对多爆炸。
