当 SQL 聚合函数返回的结果和业务预期不一致时，首先会怀疑数据库统计信息或者引擎版本，但实际上大多数异常来自几个容易被忽略的细节：JOIN 造成行数膨胀、NULL 参与计算的规则、字段类型精度以及过滤条件的位置。把这些因素逐一排查，通常能在几分钟内定位问题。
先核对数据范围与JOIN是否造成重复计算
聚合结果异常时，第一步不要修改聚合函数本身，而是确认参与聚合的基础行数是否正确。很多SUM偏大的问题，根源不在SUM，而在前面关联表时产生了行数膨胀。例如订单表 orders 和订单明细表 order_items 做一对一关联，如果使用普通JOIN，左表一行在右表有多条明细时会被复制成多行。此时对 orders.amount 求和，同一笔订单金额会被重复累加多次，结果自然比实际总金额大很多。
排查方式可以先去掉聚合，分别查看两表的行数，以及关联后的明细行数是否与预期一致。比如单独执行 SELECT COUNT(*) FROM orders 和 SELECT COUNT(*) FROM order_items，再将关联后的结果与业务侧导出的订单数对比。若关联后行数明显多于订单数，就说明JOIN条件不够严格或者存在一对多关系。确认问题后，通常有两种修正思路：先在子查询中聚合明细表，再与主表关联；或者对重复字段使用DISTINCT去重，但DISTINCT需要谨慎，因为可能掩盖真正的数据重复。
-- 错误示例：直接关联导致金额重复累计 SELECT SUM(o.amount) AS total_amount FROM orders o JOIN order_items i ON o.order_id = i.order_id;
修正时如果只需要统计订单总金额，可以先在明细表聚合，或者使用 EXISTS 判断是否存在明细，而不是把明细逐行带入。例如：
-- 修正：先聚合明细，避免左表行复制
SELECT SUM(o.amount) AS total_amount
FROM orders o
WHERE EXISTS (
SELECT 1 FROM order_items i WHERE i.order_id = o.order_id
);
如果业务上确实需要明细级别的统计，也要明确聚合粒度。例如按订单粒度统计商品数量，可以在子查询中先按 order_id 计算 SUM(i.quantity)，再与订单表关联，避免对金额字段重复求和。总之，确认行数是聚合问题排查的第一步，也是最容易被忽略的一步。
NULL值在聚合函数中的行为要分清
NULL对聚合函数的影响比想象中更大，而且不同函数处理规则并不相同。COUNT(*) 统计所有行，包括整行都是NULL的情况；但 COUNT(column) 只统计该列非NULL的行数。SUM、AVG、MAX、MIN 会直接忽略NULL值。这个规则看似简单，实际计算时会导致结果偏差。例如一张用户表中有10行，其中3行的age列为NULL，那么 COUNT(*) 返回10，COUNT(age) 返回7，AVG(age) 则只对7个非NULL值求平均。很多人以为AVG的分母是10，结果自然对不上。
另一个常见问题是分组列中的NULL。GROUP BY会把所有NULL归入同一组，所以当业务上NULL代表未知值时，这一组可能混入多个不同含义的记录。比如按省份统计销售额，province列为NULL的订单会被全部归到一组，导致该组金额异常增大。解决方式可以在分组前用COALESCE或CASE把NULL转换成明确的业务值，比如将未填写省份统一标记为未知，或者单独过滤掉。
-- 明确NULL的统计差异
SELECT
COUNT(*) AS total_rows,
COUNT(age) AS non_null_age,
SUM(age) AS sum_age,
AVG(age) AS avg_age
FROM users;
如果希望AVG把NULL当作0参与分母，需要手动转换，例如 AVG(COALESCE(age, 0))。但这样做会改变业务含义，必须确认NULL在业务上是否等同0。金额类字段尤其要小心，SUM会忽略NULL导致结果偏小，但若NULL代表未发生交易，忽略反而是正确的。先明确业务口径，再决定是否需要 COALESCE 或过滤，是避免聚合计算与业务预期不一致的关键。
数值类型与浮点精度可能引入隐性误差
即使数据行数和NULL处理都正确，聚合结果仍可能在小数位出现偏差，这通常来自字段类型。使用 FLOAT 或 DOUBLE 存储金额、比率等精确数值时，二进制浮点表示会导致精度丢失。例如SUM(0.1 + 0.2) 在浮点类型下可能得到 0.30000000000000004。这类误差在单次计算中不明显，但聚合大量行后会累积放大，最终报表金额与财务系统对不上。
数据库中的DECIMAL类型以字符串形式存储精确十进制数值，适合金额、数量等需要精确结果的场景。如果建表时已经使用了FLOAT，排查时可以先用 CAST 把字段转成 DECIMAL 再聚合，看结果是否与预期一致。例如 SUM(CAST(amount AS DECIMAL(18,2)))。长期方案是修改表结构，将金额字段改成DECIMAL，并保留足够的精度位数。对于金额，通常使用DECIMAL(18,2)或更高精度，避免除法运算后的无限小数。
-- 浮点求和可能产生尾差 SELECT SUM(amount) AS float_sum FROM payments WHERE amount IS NOT NULL; -- 使用DECIMAL修正 SELECT SUM(CAST(amount AS DECIMAL(18,2))) AS decimal_sum FROM payments WHERE amount IS NOT NULL;
另外，整数除法也会悄悄改变结果。在多数数据库中，两个整数相除会返回整数，例如 SELECT 5 / 2 得到2而不是2.5。如果AVG计算涉及整数字段，数据库通常会自动转换，但手工写 SUM(value) / COUNT(*) 时，如果两个字段都是整型，结果可能被截断。解决方式是把分子或分母显式转换为小数，例如 SUM(value) * 1.0 / COUNT(*)，这样除法会按小数规则进行。处理完类型问题后，聚合结果的精度通常能恢复到业务要求。
过滤条件的位置决定了聚合基数
WHERE 和 HAVING 虽然都是过滤，但执行阶段不同。WHERE 在分组和聚合之前运行，它决定哪些行参与计算；HAVING 在聚合之后运行，它决定哪些分组被保留。如果把本应放在 HAVING 的条件误写到 WHERE，聚合范围会缩小，结果自然异常。例如要查询订单总额超过10000的客户，但错误地在 WHERE 中过滤单笔金额超过10000的订单，再按客户SUM，会漏掉那些单笔金额小但累计超过10000的客户。
排查时先确认过滤条件的业务含义：如果条件描述的是原始行的属性，应该放WHERE；如果条件描述的是聚合后的结果，应该放HAVING。一个常见对比是，统计部门平均工资高于10000的部门，并希望排除工资低于3000的实习生。如果是排除实习生后再计算平均工资，条件应放WHERE；如果是计算全体平均工资后再筛掉均值低于10000的部门，条件应放HAVING。两者位置不同，结果完全不同。
-- 错误：在WHERE中过滤聚合结果条件 SELECT customer_id, SUM(order_amount) AS total_amount FROM orders WHERE SUM(order_amount) > 10000 GROUP BY customer_id; -- 正确：使用HAVING过滤分组 SELECT customer_id, SUM(order_amount) AS total_amount FROM orders GROUP BY customer_id HAVING SUM(order_amount) > 10000;
窗口函数的情况稍复杂。像 ROW_NUMBER、RANK、SUM OVER 等窗口函数在分组聚合之后计算，如果要在窗口函数结果上继续过滤，不能直接在 WHERE 中使用别名，需要包一层子查询。例如按部门给员工薪资排名后取前3名，直接写 WHERE rn <= 3 会报错或无效，必须把排名结果放入子查询再过滤。理解过滤顺序后，很多看似奇怪的聚合结果都能从逻辑上找到原因。
-- 窗口函数过滤需要子查询
SELECT * FROM (
SELECT employee_id, department_id, salary,
ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rn
FROM employees
) AS ranked
WHERE rn <= 3;
聚合函数异常很少是数据库缺陷，更多是SQL逻辑与业务口径不一致。排查路径可以固定为四步：先核对原始行数和分组基数，再确认NULL处理是否符合预期，然后检查字段类型和精度，最后复核WHERE与HAVING的位置。逐步排查比盲目修改SQL更高效，也能避免用DISTINCT或ROUND掩盖真实问题。