正确答案是：子查询应先过滤再聚合，否则金额汇总不一致。典型错误是外层WHERE依赖子查询结果却未在子查询中加时间等关键条件，导致全量数据参与聚合；正确做法是在子查询内完成过滤与聚合，或改用JOIN下推条件。
子查询里 GROUP BY 和外层 WHERE 顺序搞反了
金额汇总不一致，八成是子查询先聚合、后过滤，但实际业务要求先过滤再聚合。比如想算「2024年活跃用户的订单总金额」，却写了：
SELECT SUM(amount) FROM orders WHERE user_id IN (SELECT user_id FROM users WHERE status = 'active')——这会把所有年份的订单都算进去。正确做法是让子查询返回带时间条件的聚合结果，或改用 JOIN + 条件下推。
常见错误现象：总数比预期大很多，尤其在用户/订单量大的表中更明显。
实操建议：
- 检查子查询是否遗漏了关键过滤字段（如
created_at、status） - 把子查询单独执行一遍，看返回的
user_id列是否包含不该出现的记录 - 优先考虑用
JOIN替代IN子查询，更容易加索引和调试
NULL 值参与 SUM 或 COUNT 导致漏计
子查询结果里有 NULL，而外层又用了 SUM() 或 COUNT(*)，容易误判。比如：
SELECT SUM((SELECT amount FROM payments p WHERE p.order_id = o.id)) FROM orders o——只要某订单没付款记录，子查询返回
NULL，SUM(NULL) 就是 NULL，整行被忽略。这不是语法错，是逻辑陷阱。使用场景：关联支付、退款、对账类汇总时高频出现。
实操建议：
- 子查询必须明确处理空值，例如用
COALESCE((SELECT ...), 0) - 避免在
SUM()外层套标量子查询，改用LEFT JOIN+GROUP BY - 用
COUNT(column)而非COUNT(*)留意是否漏掉 NULL 行
子查询返回多行却没加聚合或限制
标量子查询（用在 SELECT 列或 WHERE 条件里）如果返回多行，MySQL 报错 Subquery returns more than 1 row，但 PostgreSQL 或某些 ORM 可能静默取第一行，导致金额对不上。
典型错误写法：
SELECT id, (SELECT amount FROM refunds r WHERE r.order_id = o.id) AS refund FROM orders o——一个订单可能有多次退款，子查询就崩或取错值。
实操建议：
- 标量子查询必须确保最多返回一行，加
LIMIT 1不够，得靠业务逻辑约束（如WHERE type = 'final'） - 真要取多值，改用
JOIN后聚合，例如SUM(r.amount) - 用
EXISTS替代= (SELECT ...)可规避多行问题，但不能拿回数值
子查询里用了不可重复读的函数或变量
比如在子查询里调用 NOW()、@var 或窗口函数，不同执行时刻结果不同，导致两次跑数金额不一致。尤其在报表定时任务里，这种“看似稳定实则漂移”的问题最难排查。
性能影响：含函数的子查询无法有效利用索引，还可能触发全表扫描。
实操建议：
- 把
NOW()这类计算提到外层，作为参数传入子查询（如用WHERE created_at > ?） - 避免在子查询中引用用户变量
@var，MySQL 8.0+ 已不推荐 - 窗口函数（如
ROW_NUMBER()）不能直接用于标量子查询，会报错，需提前物化成临时表
WHERE、忽略一个 NULL、没意识到 IN 的去重行为，结果就偏了。 
