MySQL中更新多列须用JOIN派生表：UPDATE t1 JOIN (SELECT ...) AS s ON t1.id=s.id SET t1.a=s.x, t1.b=s.y；子查询必须别名，JOIN需一对一，不可直接引用外层表。
MySQL 中用子查询一次更新多列的正确写法
MySQL 不支持在 UPDATE 语句的 SET 子句中直接写多个标量子查询（比如 SET a = (SELECT x FROM t2 WHERE ...), b = (SELECT y FROM t2 WHERE ...)），因为每个子查询会独立执行、可能关联不一致，还容易触发 “You can’t specify target table for update in FROM clause” 错误。
真正可靠的做法是用 JOIN + 子查询派生表（derived table）一次性关联更新：
UPDATE orders o
JOIN (
SELECT order_id, total_amount, status_code
FROM order_summary
WHERE updated_at > '2024-01-01'
) s ON o.order_id = s.order_id
SET o.total = s.total_amount,
o.status = s.status_code;
- 子查询必须有别名（如这里的
s），否则 MySQL 报错Every derived table must have its own alias -
JOIN条件要确保一对一匹配；如果子查询结果对同一主表行出现多次，会导致更新被重复执行（结果不可控） - 不能在子查询中直接引用外层表（如
o.order_id），否则报错；需靠JOIN显式关联
PostgreSQL 支持更直观的 FROM 子句更新
PostgreSQL 允许在 UPDATE 后直接跟 FROM，语法更贴近直觉，也天然支持多列赋值：
UPDATE orders
SET total = s.total_amount,
status = s.status_code
FROM order_summary s
WHERE orders.order_id = s.order_id
AND s.updated_at > '2024-01-01';
- 不需要给子查询起别名再
JOIN，FROM后直接接子查询或表即可 -
WHERE条件里可以混合主表和子查询表的字段，关联逻辑更灵活 - 若
order_summary中一个order_id出现多次，PostgreSQL 只取其中一行（行为未定义），建议提前用DISTINCT ON或聚合保证唯一性
SQL Server 的 UPDATE ... FROM 陷阱
SQL Server 的 UPDATE ... FROM 看似简单，但默认行为容易出错：它不强制要求关联唯一性，也不会报错，而是静默地对主表某行执行多次更新（最后生效的是最后一次匹配）。
- 务必在子查询中预先去重，例如用
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC)取最新一条 - 避免写成
UPDATE o SET ... FROM orders o, order_summary s WHERE ...—— 这是旧式隐式 JOIN，可读性差且易误写成笛卡尔积 - 推荐显式写法：
UPDATE o SET total = s.total_amount, status = s.status_code FROM orders o INNER JOIN ( SELECT order_id, total_amount, status_code, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC) rn FROM order_summary WHERE updated_at > '2024-01-01' ) s ON o.order_id = s.order_id AND s.rn = 1;
跨数据库迁移时最常被忽略的兼容性点
不同数据库对“子查询更新多列”的语义容忍度差异极大，不是语法换一下就能跑通。
- MySQL 5.7+ 和 8.0 对派生表的物化策略不同，可能导致子查询执行次数突增，影响性能
- SQLite 完全不支持
UPDATE ... FROM或JOIN更新，只能用触发器或分步执行 - Oracle 需用
MERGE，且USING子句中的子查询不能引用目标表，否则报ORA-00904 - 所有数据库都要求子查询返回的列数、类型、顺序与
SET列严格对应；少一列或类型不兼容，直接报错而非静默忽略
实际写的时候，先确认目标数据库版本和方言能力，再决定用 JOIN 派生表、FROM 子句，还是退回到临时表中转——别让“看起来像能跑”骗过自己。
