子查询在UPDATE中必须返回单值，否则报错；父子级扣减需分步或递归执行，避免快照一致性问题；推荐LEFT JOIN+COALESCE替代相关子查询，并配合SELECT...FOR UPDATE加锁防并发超扣。
子查询必须用 SELECT 返回单值，否则 UPDATE 会报错
直接在 UPDATE 的 SET 子句里写多行子查询（比如漏加 WHERE 或没用聚合函数），MySQL 会抛出 Subquery returns more than 1 row。PostgreSQL 则可能报 more than one row returned by a subquery used as an expression。这不是语法错误，是语义限制：赋值目标只能接收一个标量。
实操建议：
- 检查子查询是否加了足够约束条件（如
AND parent_id = t1.id），确保每条更新行对应唯一子查询结果 - 若需汇总子项库存，强制用
SUM()、COALESCE(SUM(...), 0)，避免NULL导致扣减失效 - 测试时先用
SELECT拆解子查询，确认返回行数和值域是否符合预期
父子级扣减必须按层级顺序执行，不能依赖单条 UPDATE
库存扣减本质是状态变更，父级扣减量依赖子级实际扣减后的剩余值。单条 SQL 无法实现“先算子项、再算父项”的链式依赖——因为所有行的计算在同一快照下并发进行，子项的更新尚未落盘，父项子查询读到的仍是旧值。
常见错误现象：父级扣减量恒为 0，或扣减量固定等于初始子项总和（未反映中间已扣减状态）。
实操建议：
- 拆成两步：先
UPDATE所有叶子节点（无子项的item_type = 'leaf'），再UPDATE父节点（通过关联子表聚合） - 若层级深（>3 层），改用递归 CTE（PostgreSQL/SQL Server）或临时表逐层迭代，避免自连接爆炸
- 在事务中执行，加上
SELECT ... FOR UPDATE锁住相关行，防止并发修改导致超扣
JOIN 子查询比相关子查询性能高，但要注意 NULL 处理
用 UPDATE t1 JOIN (SELECT parent_id, SUM(quantity) AS total_used FROM t2 GROUP BY parent_id) t2 ON t1.id = t2.parent_id 替代 SET stock = stock - (SELECT SUM(...) FROM t2 WHERE t2.parent_id = t1.id)，可显著减少子查询重复执行次数（尤其当父表行数多时）。
但注意：JOIN 会自动过滤掉没有子项的父记录（INNER JOIN），导致这些父项库存不被更新；而相关子查询返回 NULL，若没用 COALESCE 包裹，stock - NULL 结果也是 NULL。
实操建议：
- 统一用
LEFT JOIN+COALESCE(t2.total_used, 0)，保证所有父项都被处理 - 在子查询中提前
WHERE status = 'confirmed'过滤无效子项，别把过滤逻辑丢给外层ON - 对
parent_id和子表关联字段建联合索引，例如INDEX(parent_id, status, quantity)
并发场景下，子查询结果可能过期，必须加锁或重试
即使用了 SELECT ... FOR UPDATE，如果子查询在 UPDATE 之前执行（比如在触发器或应用层预查），那查到的子项库存可能是旧的。两个事务同时读到同一子项剩余 10，各自扣 5，最终变成 0 而非 5。
真正安全的做法是：把子项扣减和父项更新放在同一个原子操作里，且子项行被锁定。
实操建议：
- 在事务开头，用
SELECT id, stock FROM items WHERE id IN (/*所有涉及的子项ID*/) FOR UPDATE预锁 - 若使用嵌套子查询做扣减，确保子查询的
FROM表也参与了FOR UPDATE锁定（MySQL 支持UPDATE ... JOIN ... FOR UPDATE） - 捕获死锁异常（
Deadlock found when trying to get lock），在应用层做指数退避重试
复杂点在于：父子关系可能跨多个物理表，锁粒度难控制；容易被忽略的是，子查询里哪怕只读取 quantity 字段，只要没加锁，就可能读到脏数据。
