相关子查询不能直接用于UPDATE语句，因SQL标准及主流数据库为避免数据一致性风险而禁止在UPDATE中直接引用目标表；需用派生表、JOIN或FROM子句绕过限制，并结合行级锁与应用层重试防超卖。
相关子查询为什么不能直接用于UPDATE语句
SQL标准中，绝大多数数据库（MySQL 5.7+、PostgreSQL、SQL Server）明确禁止在 UPDATE 的 SET 子句里直接引用同一张表的子查询（尤其是相关子查询），会报类似 ERROR 1093 (HY000): You can't specify target table 'stock' for update in FROM clause（MySQL）或“cannot modify a table and select from the same table in a subquery”（PostgreSQL）。这不是语法写得不对，而是引擎为避免数据一致性风险做的硬性限制。
真正能跑通的“动态扣减”，本质是把相关子查询从 UPDATE 主体中剥离出去——要么用派生表绕过限制，要么改用 JOIN，要么交给应用层分步处理。
MySQL中用派生表实现安全的库存扣减
MySQL允许对派生表（即子查询结果别名）执行UPDATE，只要该派生表不直接引用原表名。这是最常用且兼容性好的方案。
- 假设订单表
orders有product_id和quantity，库存表stock有product_id和available - 目标：对每个订单，将对应商品的
available减去该订单数量，但不能低于 0 - 关键点：必须用
(SELECT ...)构造匿名派生表，再JOIN回stock
UPDATE stock s JOIN ( SELECT o.product_id, SUM(o.quantity) AS total_qty FROM orders o WHERE o.status = 'confirmed' GROUP BY o.product_id ) t ON s.product_id = t.product_id SET s.available = GREATEST(s.available - t.total_qty, 0);
注意：GREATEST() 防止负库存；若某商品无订单，不会被更新（JOIN 天然过滤）；若需处理零订单商品，改用 LEFT JOIN + COALESCE(t.total_qty, 0)。
PostgreSQL中用FROM子句替代相关子查询
PostgreSQL支持在 UPDATE 中使用 FROM 关键字关联其他表或子查询，比MySQL更直观，也天然规避了相关子查询限制。
- 同样场景下，可直接关联聚合子查询
- 无需派生表包装，但子查询必须有别名
-
WHERE条件要显式控制更新范围，否则可能误更新
UPDATE stock s SET available = GREATEST(s.available - t.total_qty, 0) FROM ( SELECT product_id, SUM(quantity) AS total_qty FROM orders WHERE status = 'confirmed' GROUP BY product_id ) t WHERE s.product_id = t.product_id;
如果想同时处理“未下单商品”（设为冻结状态），可在 WHERE 加上 s.available IS NOT NULL 等业务条件，避免全表扫。
为什么不能在WHERE里用相关子查询校验库存是否充足
有人试图写 WHERE (SELECT available FROM stock s2 WHERE s2.product_id = orders.product_id) >= orders.quantity 来做前置校验，这在 UPDATE ... FROM 或 UPDATE ... JOIN 中看似可行，但存在严重隐患：
- 子查询执行时机不确定，可能读到旧快照（尤其在RC隔离级别下）
- 并发下单时，两个事务同时通过校验，然后都执行扣减，导致超卖
- 即使加了
SELECT ... FOR UPDATE，在UPDATE语句里嵌套它也不被多数引擎支持
真正防超卖必须靠行级锁 + 原子更新，比如先 SELECT ... FOR UPDATE 查当前库存，再在应用层判断并执行带 WHERE available >= ? 的UPDATE，失败则重试。相关子查询在这里只是幻觉，不是解法。
实际落地时，扣减逻辑越靠近数据库原子操作越好，但校验和重试策略得由业务代码兜底——子查询本身不解决并发问题。
