先抛个直接的问题：当我们想在 UPDATE 语句里，根据另一张表的数据来更新当前表的字段时，大多数人第一反应就是写个子查询。想法很自然，但实际跑起来，MySQL 和 PostgreSQL 会给你不同的“脸色”。这背后涉及语法限制、NULL 值陷阱，还有性能上的暗坑。下面就把这些关键点掰开揉碎，说清楚。
UPDATE 中用子查询关联另一张表更新字段，可行但有陷阱
MySQL 和 PostgreSQL 都支持在 UPDATE 里嵌套子查询去引用其他表，但语法和限制差异大得离谱。最常见的翻车现场是直接写成 UPDATE t1 SET col = (SELECT col FROM t2 WHERE t2.id = t1.id)，却忘了加 WHERE EXISTS 或者处理 NULL 的情况，结果不匹配的行直接被设成 NULL，数据说没就没。
关键判断点：如果目标数据库是 MySQL，子查询不能直接引用被更新的表——会报错 You can't specify target table 't1' for update in FROM clause；PostgreSQL 则允许，但相关子查询的执行逻辑需要小心，一不小心就踩坑。
MySQL 下绕过“不能引用自身表”限制的三种实操方式
MySQL 把子查询当作临时派生表来处理，所以核心思路就是“伪装”掉对原表的直接引用。具体有这几个路子：
- 用
JOIN替代子查询：UPDATE t1 JOIN t2 ON t1.id = t2.t1_id SET t1.status = t2.new_status—— 最简洁，性能也好，是优先推荐的做法。 - 嵌套一层子查询（俗称“双括号技巧”）：
UPDATE t1 SET status = (SELECT new_status FROM (SELECT t2_id, new_status FROM t2) AS tmp WHERE tmp.t2_id = t1.id)—— 多一层 SELECT 就绕过了校验，但可读性比较差，后期维护可能会骂人。 - 用变量暂存结果（仅限单行更新场景）：
SET @val := (SELECT new_status FROM t2 WHERE t2.t1_id = 123); UPDATE t1 SET status = @val WHERE id = 123—— 不适用于批量更新，而且事务里要小心变量作用域，容易出幺蛾子。
PostgreSQL 中相关子查询的写法与 NULL 风险
PostgreSQL 允许在 UPDATE 的 SET 子句里直接写相关子查询，但必须时刻记住：子查询不返回任何行时，SET 的值就会变成 NULL。这个坑实在太容易被忽略了。
举个例子：UPDATE orders SET customer_name = (SELECT name FROM customers WHERE customers.id = orders.customer_id) —— 如果某条 orders 记录的 customer_id 在 customers 表中找不到，那这个订单的 customer_name 就被清空，数据完整性直接崩了。
- 加
WHERE EXISTS限定只更新有匹配的行：UPDATE orders SET customer_name = (SELECT name FROM customers WHERE customers.id = orders.customer_id) WHERE EXISTS (SELECT 1 FROM customers WHERE customers.id = orders.customer_id) - 用
COALESCE保底：SET customer_name = COALESCE((SELECT name FROM customers WHERE customers.id = orders.customer_id), orders.customer_name)—— 匹配不到就保持原值，安全第一。 - 注意子查询最多返回一行，否则会报错
more than one row returned by a subquery used as an expression，这个错误在数据有重复时特别常见。
跨库或大表更新时的性能与锁注意事项
子查询式的 UPDATE 在数据量一大就容易慢，尤其是子查询没走索引，或者被更新表和关联表都缺乏合适的连接键索引。这种情况必须提前预防。
- 务必确认
WHERE条件和子查询中的关联字段都有索引，比如t2.t1_id和t1.id都建了索引，否则就是全表扫的噩梦。 - MySQL 的
JOIN UPDATE默认使用行级锁，但若子查询触发全表扫描，可能升级为表锁，并发写入直接跪；PostgreSQL 的相关子查询在执行时会对子查询涉及的表加共享锁，也会影响并发。 - 生产环境批量更新前，一定要先用
EXPLAIN UPDATE ...（PostgreSQL）或EXPLAIN FORMAT=TREE UPDATE ...（MySQL 8.0+）看执行计划，避免隐式全表扫描，否则上线后哭都来不及。
真正容易被忽略的是：子查询在每次更新行时都会重新执行一次。哪怕只改 100 行，关联表就被查了 100 次——这比一次 JOIN 扫描高效不了多少，反而更难优化。所以，能用 JOIN 就别偷懒，别在子查询上钻牛角尖。
