MySQL中UPDATE配合子查询更新另一张表字段时，必须使用标量子查询（单行单列），否则报错；禁止在子查询FROM中引用被更新表，应改用JOIN方式：UPDATE t1 JOIN t2 ON t1.ref_id = t2.id SET t1.col = t2.val。
MySQL中UPDATE配合子查询更新另一张表的字段
MySQL 5.7+ 支持在 UPDATE 语句中直接用关联子查询更新目标表，但必须确保子查询是「标量子查询」（返回单行单列），否则会报错 Subquery returns more than 1 row。常见错误是没加 WHERE 条件或没用聚合/限制导致多行返回。
典型写法是：UPDATE t1 SET col = (SELECT t2.val FROM t2 WHERE t2.id = t1.ref_id)。注意：子查询里不能引用被更新的表（t1）作为 FROM 源——MySQL 会拒绝执行并提示 You can't specify target table 't1' for update in FROM clause。
- 若需规避该限制，改用
JOIN形式：UPDATE t1 JOIN t2 ON t1.ref_id = t2.id SET t1.col = t2.val - 子查询中若含
GROUP BY或ORDER BY，必须搭配LIMIT 1（否则语法不通过） - 性能上，子查询方式在
t2.ref_id缺少索引时会全表扫描，比JOIN更慢
PostgreSQL中用FROM子句实现跨表UPDATE
PostgreSQL 不支持 MySQL 那种括号子查询赋值写法，但提供更清晰的 UPDATE ... FROM 语法：UPDATE t1 SET col = t2.val FROM t2 WHERE t1.ref_id = t2.id。它本质是隐式 JOIN，语义明确且允许复杂关联。
容易踩的坑是 WHERE 条件写错位置——必须放在整个语句末尾，不是子句里；漏掉会导致整张 t1 表被更新为同一值（比如 t2 第一行的 val）。
- 支持多表
FROM：UPDATE t1 SET col = t3.val FROM t2 JOIN t3 ON t2.id = t3.t2_id WHERE t1.ref_id = t2.id - 若
t2中存在多个匹配t1.ref_id的记录，PostgreSQL 默认取任意一行（无序），需用DISTINCT ON或子查询预过滤 - 执行前务必加
EXPLAIN看执行计划，避免因缺失t2.id索引引发嵌套循环全表扫描
SQL Server中用UPDATE + JOIN语法更新关联数据
SQL Server 不允许标准 ANSI SQL 的子查询赋值写法，但支持带 FROM 的扩展语法：UPDATE t1 SET t1.col = t2.val FROM t1 INNER JOIN t2 ON t1.ref_id = t2.id。注意：这里 t1 必须显式出现在 FROM 子句中，否则报错 Invalid column name。
和 PostgreSQL 不同，SQL Server 的 FROM 是必需的中间步骤，不是可选修饰。若忘记写 INNER JOIN 而只写 LEFT JOIN，未匹配的行会被设为 NULL——这常被误认为“没更新”，其实是逻辑生效了。
- 推荐始终用
INNER JOIN显式限定范围，避免意外 NULL 写入 - 若需按聚合结果更新（如统计数量），必须先用 CTE 或派生表预计算：
WITH cnt AS (SELECT ref_id, COUNT(*) c FROM t2 GROUP BY ref_id) UPDATE t1 SET cnt = cnt.c FROM t1 JOIN cnt ON t1.id = cnt.ref_id - 在大表上执行前，确认
t2.ref_id和t1.id均有索引，否则可能锁表超时
跨数据库兼容写法：用临时表或应用层分步处理
当需要同时适配 MySQL、PostgreSQL、SQL Server 时，原生语法差异太大，硬写统一 SQL 几乎不可行。最稳妥的方式是放弃单条 SQL，改用两步：先查出映射关系存入临时表（或内存结构），再批量更新。
例如：先 SELECT t1.id, t2.val INTO #tmp_update FROM t1 JOIN t2 ON t1.ref_id = t2.id（SQL Server），或用应用代码读取后构造 UPDATE t1 SET col = ? WHERE id = ? 批量执行。虽然多一次网络往返，但逻辑可控、调试方便、事务边界清晰。
- 临时表方案在 PostgreSQL 中用
CREATE TEMP TABLE，MySQL 中用CREATE TEMPORARY TABLE，语法接近但细节不同 - 应用层批量更新要注意参数个数限制（如 MySQL 默认
max_allowed_packet），需分批提交（如每 1000 行一组） - 真正难处理的是「更新过程中源表数据变更」——临时表或应用缓存无法自动感知，必须靠业务层加锁或版本控制
