MySQL 5.7+ 禁止 UPDATE 中子查询直引目标表，因存在脏读与锁风险；须用派生表（SELECT * FROM (...) AS alias）隔离结果集，即使单列也需嵌套。
UPDATE语句里子查询不能直接引用被更新的表
MySQL 5.7+ 和大多数主流数据库（如 PostgreSQL、SQL Server）明确禁止在 UPDATE 中对目标表做「同一层级」的子查询引用，否则会报错 ERROR 1093 (HY000): You can't specify target table 'xxx' for update in FROM clause。这不是语法写错了，而是引擎为避免数据一致性风险做的硬性限制。
本质是：更新过程中，子查询若直接读取正在修改的表，可能读到中间态脏数据，或触发不可预测的锁行为。所以必须绕过「直引」，把子查询结果先隔离出来。
- 最稳妥的做法是用派生表（即子查询套一层
SELECT * FROM (...) AS alias），让优化器把它当作临时结果集处理 - PostgreSQL 支持
FROM子句关联更新（更直观），但 MySQL 不支持，别混用 - 如果子查询涉及聚合或窗口函数，确保外层 UPDATE 不会因多行匹配导致意外重复更新
MySQL中用派生表绕过“目标表限制”
核心技巧就是给子查询加个匿名别名，强制它变成一个不可修改的中间结果集。哪怕只查一列，也得包一层。
AS tmp
- 如果需要更新字段值来自子查询结果（比如同步最新价格），改用
JOIN形式更安全：UPDATE t1 JOIN (SELECT ...) AS t2 ON t1.id = t2.id SET t1.price = t2.new_price - 避免在子查询里用
ORDER BY或LIMIT——除非你明确知道只取一行且业务允许不确定性 - 执行前务必加
SELECT验证子查询结果，比如先跑SELECT * FROM (子查询) AS tmp
PostgreSQL里用FROM子句更自然
PostgreSQL 允许在 UPDATE 后直接跟 FROM，语义清晰，也不用套壳：
UPDATE orders SET status = 'shipped', updated_at = NOW() FROM ( SELECT order_id FROM orders WHERE created_at <p>这种写法本质是隐式 JOIN，性能通常优于 MySQL 的派生表方案，且支持多表关联更新。</p>
- 注意
WHERE条件必须显式关联主表和子查询别名，漏掉会导致笛卡尔积更新 - 如果子查询返回重复
order_id，PostgreSQL 仍只更新一次（按主表行唯一性），但逻辑上应保证子查询键唯一 - 想看实际影响行数？加
RETURNING *尾部即可返回被改的记录
批量更新前必须检查的三件事
子查询嵌套本身不危险，危险的是没验证就执行。尤其线上环境，一条 UPDATE 可能锁表几分钟。
- 确认子查询返回的行数合理：用
SELECT COUNT(*) FROM (你的子查询) AS t先估算量级 - 检查 WHERE 条件是否命中索引：用
EXPLAIN看子查询和主表扫描方式，避免全表扫描拖慢整个库 - 测试环境先加
LIMIT 10（MySQL）或RETURNING *（PostgreSQL）跑通逻辑，再删掉限制正式执行
真正容易被忽略的是锁粒度——MySQL 的 UPDATE ... WHERE 默认加行级写锁，但如果子查询走不到索引，可能升级成表锁。这点在高并发场景下比语法细节更致命。
