聚合子查询错误源于逻辑偏差而非语法报错，需从数据与语义两方面排查：确保子查询标量化、GROUP BY覆盖非聚合字段、处理NULL与类型转换、区分WHERE与HAVING时机、厘清嵌套聚合语义。
聚合子查询返回错误结果，通常不是语法报错，而是数据逻辑偏差——比如COUNT少算、SUM偏小、GROUP BY分组错乱。得从数据本身和语义约束两头查。
检查子查询是否真被当作标量使用
聚合子查询在WHERE或SELECT列表中必须返回单行单列，否则直接报错（如Subquery returns more than 1 row）。但即使它“不报错”，也可能因缺失关联条件变成非相关子查询，扫全表后聚合出错。
- 常见错误：写
(SELECT COUNT(*) FROM logs WHERE type = 'error')放在SELECT里——它确实只返回一行，但统计的是全局错误数，不是当前订单的错误日志数 - 正确做法：补上外层引用，例如
(SELECT COUNT(*) FROM logs l WHERE l.order_id = o.id AND l.type = 'error') - 验证方式：单独执行该子查询，把外层变量替换成真实值，看结果是否符合预期
确认GROUP BY是否覆盖所有非聚合字段
MySQL 5.7+ 和 PostgreSQL 严格模式下，SELECT a, b, COUNT(*) FROM t GROUP BY a会报错；宽松模式下虽能跑，但b的值是随机取的某一行，不可靠。
- 错误现象：
COUNT(*)数字对，但MAX(created_at)和status不匹配——说明status没参与分组，数据库随便挑了一行 - 修复方法：要么把
status加进GROUP BY，要么用MAX(status)或ANY_VALUE(status)（MySQL）明确语义 - 注意：
ANY_VALUE()不是兜底函数，它只是关闭校验——若业务真需要“每个分组里最新一条的状态”，就得用窗口函数或关联子查询
排查NULL和隐式类型转换对聚合的影响
SUM()、AVG()、COUNT(col)默认跳过NULL，而COUNT(*)不跳；字符串字段参与数值聚合时，MySQL可能把'12abc'转成12，'abc'转成0。
- 先查数据质量：
SELECT COUNT(*), COUNT(amount), SUM(amount), COUNT(NULLIF(amount, 0)) FROM orders - 如果
COUNT(amount)远小于COUNT(*)，说明大量amount为NULL，需确认是否应视作0——用SUM(COALESCE(amount, 0)) - 检查类型：
SELECT amount, LENGTH(amount), amount + 0 FROM orders LIMIT 5，看是否出现意外转0或警告
警惕WHERE与HAVING的过滤时机差异
WHERE在聚合前过滤行，HAVING在聚合后过滤组。用错会导致结果数量或数值完全不对。
- 典型错误：想查“订单总额超1000的用户”，却写成
WHERE SUM(amount) > 1000——语法直接报错，因为SUM()不能在WHERE里用 - 正确写法：
GROUP BY user_id HAVING SUM(amount) > 1000 - 更隐蔽的问题：在
WHERE里过滤了不该过滤的行，比如WHERE status != 'cancelled'漏掉了已取消但金额已记账的订单，导致SUM()偏低
最易被忽略的是子查询里的聚合和外层查询的聚合嵌套层级——比如在SELECT里套一层(SELECT MAX(price) FROM items WHERE order_id = o.id)，再对这个结果做AVG()，实际算的是“每单最高价的平均值”，而非“所有商品价的平均值”。业务语义一旦错位，再怎么调函数也没用。
