子查询不能自动重算历史数据，需显式逻辑；用关联子查询聚合order_items、refunds等表可重算实付金额；coalesce防null，必须关联外层order_id；exists替代join可避免因一对多导致的重复计费。
子查询不能直接“动态重算”历史订单数据——它只是按执行时刻的快照取数；真要重算，得靠明确的重计算逻辑+可复用的子查询结构，而不是指望子查询自动响应上游变化。
子查询里用聚合函数重算单个订单的实付金额
常见场景：订单表 orders 存了原始金额，但实际支付可能含优惠、退款、运费调整，这些分散在 order_items、refunds、shipping_logs 表里。直接查 orders.total_amount 已不可信。
这时用相关子查询重新聚合更可靠：
SELECT
o.order_id,
o.created_at,
(SELECT COALESCE(SUM(i.price * i.qty), 0)
FROM order_items i
WHERE i.order_id = o.order_id) AS items_sum,
(SELECT COALESCE(SUM(r.amount), 0)
FROM refunds r
WHERE r.order_id = o.order_id) AS refund_sum,
(SELECT COALESCE(MAX(s.fee), 0)
FROM shipping_logs s
WHERE s.order_id = o.order_id) AS shipping_fee,
COALESCE(items_sum, 0) - COALESCE(refund_sum, 0) + COALESCE(shipping_fee, 0) AS recalculated_paid
FROM orders o
WHERE o.created_at >= '2024-01-01';
注意：COALESCE 防空值导致整行变 NULL；子查询必须关联外层 o.order_id，否则变成标量子查询报错或结果错乱。
用子查询替代 JOIN 做条件过滤，避免重复计费
当需要“只保留至少有一笔有效支付的订单”时，如果用 JOIN refunds 再 GROUP BY，容易因一对多把订单行数放大，影响主表统计口径。
改用 EXISTS 子查询更安全：
SELECT *
FROM orders o
WHERE EXISTS (
SELECT 1
FROM payments p
WHERE p.order_id = o.order_id
AND p.status = 'success'
AND p.created_at <p>关键点：</p>
-
EXISTS不返回数据，只判真假，性能通常优于IN（尤其子查询结果大时） - 子查询里的
p.created_at 是业务硬约束：支付不能晚于订单最后更新时间，漏掉这条件会导致逻辑倒置 - 别写成
IN (SELECT order_id FROM payments...)——万一payments.order_id有NULL，整条IN判定失效
嵌套子查询处理多层依赖：先算商品毛利，再算订单毛利
毛利 = 销售额 − 采购成本。但采购成本不在订单表，而在 purchase_records，且需匹配商品+时间（用下单时的最新采购价）。
这时得两层子查询嵌套：
SELECT
o.order_id,
o.created_at,
(SELECT SUM(
i.qty * (
SELECT COALESCE(pr.cost_price, 0)
FROM purchase_records pr
WHERE pr.sku = i.sku
AND pr.purchased_at <p>坑点很具体：</p>
- 内层子查询必须加
LIMIT 1和ORDER BY ... DESC，否则可能返回多行，报Subquery returns more than 1 row - 外层子查询不能直接引用别名
total_revenue—— 大多数数据库（MySQL/PostgreSQL）不支持在SELECT列表中跨子查询引用别名，得重复写或改用 CTE - 如果
purchase_records缺少某sku的历史采购记录，COALESCE返回 0，但业务上这可能是异常，需额外告警，不能只靠 SQL 掩盖
真正麻烦的不是写几层子查询，而是每次重算都要确认：子查询所依赖的源表数据是否已最终落库、是否有未同步的延迟、时间条件是否覆盖所有合理边界。这些没法靠 SQL 自动兜底，得靠上游数据流程保障。
