MySQL中用JOIN做UPDATE必须给目标表加别名，如UPDATE orders o JOIN customers c ON o.customer_id = c.id SET o.status = 'processed' WHERE c.country = 'CN'；PostgreSQL不支持该语法，需用UPDATE...FROM结构。
MySQL中用JOIN做UPDATE必须加别名
直接写 UPDATE t1 JOIN t2 ON ... SET t1.col = t2.val 会报错，MySQL要求被更新的表必须有别名。这是最常卡住的第一步。
正确写法是给目标表显式起别名，并在 SET 和 WHERE 中统一用该别名：
UPDATE orders o JOIN customers c ON o.customer_id = c.id SET o.status = 'processed' WHERE c.country = 'CN' AND o.status = 'pending';
- 别名
o不仅用于FROM部分，SET o.status和WHERE o.status也必须用它 - 不能写成
UPDATE orders JOIN ... SET orders.status = ...—— MySQL 不认这种写法 - 如果漏掉别名或混用原表名，错误信息通常是：
ERROR 1066 (42000): Not unique table/alias: 'orders'
PostgreSQL不支持UPDATE...JOIN语法
PostgreSQL根本没实现 UPDATE ... FROM 的 JOIN 形式（至少到15.x），强行套用 MySQL 写法会直接报错：ERROR: syntax error at or near "join"。
它用的是 UPDATE ... FROM 结构，语义接近但语法不同：
UPDATE orders SET status = 'processed' FROM customers WHERE orders.customer_id = customers.id AND customers.country = 'CN' AND orders.status = 'pending';
-
FROM后跟关联表，不写JOIN关键字 -
WHERE中必须显式写出所有连接条件和过滤条件，不能拆到ON子句 - 若
customers表有同名列（如id），需加表名前缀避免歧义，否则报column reference "id" is ambiguous
UPDATE JOIN性能差？先看执行计划
多表 UPDATE 容易慢，但瓶颈未必在 JOIN 本身——更可能是缺失索引或扫描全表。
运行前务必用 EXPLAIN 看实际执行路径：
EXPLAIN UPDATE orders o JOIN customers c ON o.customer_id = c.id SET o.status = 'processed' WHERE c.country = 'CN' AND o.status = 'pending';
- 重点检查
type列：如果是ALL（全表扫描），说明customers.country或orders.status缺少索引 -
rows值远大于预期行数？可能是连接条件没走索引，或统计信息过期（可运行ANALYZE TABLE） - 避免在 WHERE 中对字段用函数，比如
WHERE DATE(created_at) = '2024-01-01'会让索引失效
安全第一：UPDATE前务必加WHERE且先SELECT验证
没有 WHERE 的多表 UPDATE 是灾难性的，可能误改全表数据。即使写了 WHERE，逻辑错也会批量污染。
标准操作流程只有三步：
- 先把 UPDATE 的 SELECT 版本跑通：
SELECT o.id, o.status, c.country FROM orders o JOIN customers c ON ... WHERE ...，确认返回行数和内容符合预期 - 确保 WHERE 条件中所有字段都有索引支撑，尤其关联字段（
customer_id）和过滤字段（country,status） - 生产环境执行前，用
START TRANSACTION包裹，执行后立刻SELECT核查，没问题再COMMIT；出问题就ROLLBACK
跨库或大表批量更新时，WHERE 条件里漏掉关键约束（比如忘记限定 status = 'pending'），后果就是把已处理的订单又翻出来改一遍——这种错误不会报错，但业务逻辑就乱了。
