mysql中不可直接用子查询引用被更新表，需用join或双层子查询绕过；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 扫描高效不了多少，反而更难优化。
