MySQL 8.0以前及部分旧版PostgreSQL中，UPDATE语句直接嵌套子查询引用自身表会报ERROR 1093，因引擎禁止读写冲突；需用派生表（加AS别名）或JOIN绕过，确保子查询隔离且字段引用带别名。
UPDATE 语句里直接嵌套子查询更新当前表会报错
MySQL（8.0 以前）和一些旧版 PostgreSQL 不允许在 UPDATE 的 SET 或 WHERE 中，对**正在被更新的同一张表**做子查询。典型错误是：ERROR 1093 (HY000): You can't specify target table 't' for update in FROM clause。这不是语法写错了，而是引擎为避免读写冲突做的硬性限制。
根本原因在于：子查询若直接引用目标表，执行时可能产生不确定的读取快照，导致更新结果不可预期。所以必须绕过“直引本表”这个动作。
- 最稳妥的做法是把子查询结果先“脱敏”——用派生表（derived table）包一层，让优化器认为那是临时结果集，而非原表
- PostgreSQL 和 MySQL 8.0+ 支持
UPDATE ... FROM语法，更直观，但写法和语义与传统子查询不同，不能混用 - 别用视图或 CTE 当临时中转（除非明确知道它不会被物化为实际表引用），某些版本仍会触发相同报错
MySQL 5.7 / 8.0 兼容写法：用派生表绕过 ERROR 1093
核心技巧是给子查询加个外层 SELECT * FROM (子查询) AS alias，强制生成匿名临时表。即使只查一列，也得包。
UPDATE orders
SET status = 'processed'
WHERE id IN (
SELECT id FROM (
SELECT o.id
FROM orders o
JOIN order_items oi ON o.id = oi.order_id
WHERE oi.quantity > 10
) AS tmp
);注意点：
-
AS tmp别名不可省略，MySQL 要求派生表必须有别名 - 子查询里所有字段引用必须带表别名（如
o.id），否则外部包壳后字段解析会失败 - 如果要按关联结果更新字段值（比如把订单总金额设为子查询算出的 sum），就得用
JOIN方式，不能只靠IN
想用子查询结果直接赋值？改用 JOIN UPDATE 语法
当你要把子查询算出的值（比如统计值、聚合结果）写回原表字段时，IN 就不够用了。UPDATE ... JOIN 是 MySQL 更高效且可读的方式。
UPDATE orders o JOIN ( SELECT order_id, SUM(price * qty) AS total_amt FROM order_items GROUP BY order_id ) AS calc ON o.id = calc.order_id SET o.total = calc.total_amt;
这种写法本质是把子查询当“临时维度表”来关联，既避开 ERROR 1093，又支持字段级赋值。关键约束：
-
JOIN条件必须能唯一匹配（比如order_id是主键或有唯一索引），否则会意外更新多行 - 子查询里不能出现
orders表本身，只能关联其他表或聚合自身数据（通过 GROUP BY） - 如果子查询结果为空，对应主表记录的字段会被设为
NULL（除非加WHERE calc.order_id IS NOT NULL过滤）
PostgreSQL 怎么写？用 UPDATE ... FROM（不是子查询嵌套）
PostgreSQL 不走 MySQL 那套派生表绕路逻辑，它原生支持 UPDATE ... FROM，语义清晰，但要注意语法结构完全不同：
UPDATE orders SET status = 'shipped' FROM ( SELECT order_id FROM shipments WHERE shipped_at > '2024-01-01' ) AS s WHERE orders.id = s.order_id;
这里 FROM 后跟的是一个独立数据源（可以是子查询、表、CTE），不是嵌在 SET 或 WHERE 里的表达式。常见误区：
- 别写成
WHERE id IN (SELECT ...)—— 虽然合法，但性能差，且没利用好FROM的关联能力 - 如果子查询返回重复
order_id，PostgreSQL 会报错：more than one row returned by a subquery used as an expression，需确保关联键唯一或加DISTINCT - CTE 可以放前面定义再
FROM cte_name，但 CTE 本身不能引用正在更新的表（否则报错）
真正卡住人的地方往往不是语法，而是子查询是否真的“隔离”了原表引用——哪怕只多写了一个没加别名的 orders.id，或者忘了派生表的 AS xxx，就会回到报错起点。动手前先 SELECT 出子查询结果确认结构，比硬调 UPDATE 省半小时。
