聚合函数计算结果与预期不一致，排查的重点不在数据库引擎本身，而在数据形态和 SQL 执行顺序。比如 COUNT 对 NULL 行的处理、JOIN 造成的一对多重复、WHERE 与 HAVING 的过滤时机，以及浮点类型的精度误差，都会让结果看起来像算错了。先弄清这些机制，再检查查询语句，大多数问题都能很快定位。
一、COUNT 与 NULL 值：最容易忽略的差异
很多 SQL 查询结果少几行，是因为 COUNT 的参数写错了。需要先明确一个规则：COUNT(column_name) 只统计该列非 NULL 的行，而 COUNT(*) 统计所有行，包括整行存在 NULL 字段的数据。举个例子，有一张 exam_score 表，部分学生的数学成绩 math_score 为空，如果执行 SELECT COUNT(math_score) FROM exam_score;，返回的行数会小于 SELECT COUNT(*) FROM exam_score; 的结果。
这种差异也存在于 SUM 和 AVG 中：它们会跳过 NULL 值。如果业务上需要把 NULL 当作 0 处理，直接使用 AVG(score) 会让分母变小，均值偏高。正确的做法是使用 COALESCE 或标准 SQL 中的 AVG(COALESCE(score, 0))，这样 NULL 行也会参与平均计算。尤其在做成绩统计、销售指标计算时，先确认该列是否允许 NULL，再决定是否需要补值。
-- 查看总分时，NULL 行不会参与求和
SELECT
COUNT(*) AS total_rows,
COUNT(math_score) AS valid_math_rows,
SUM(math_score) AS total_math_score
FROM exam_score;
-- 如果业务上需要把 NULL 当作 0 处理
SELECT
COUNT(*) AS total_rows,
SUM(COALESCE(math_score, 0)) AS total_math_score
FROM exam_score;
另一个常见的混淆是 COUNT(DISTINCT column_name)。它同样忽略 NULL 值，并且在多列去重时要注意语法差异。例如 COUNT(DISTINCT user_id, order_date) 在部分数据库中可以按多列组合去重，而在 MySQL 中可能不支持多列 COUNT(DISTINCT)，需要改写为子查询或拼接字段。遇到去重计数不对时，先确认数据库版本对多列去重的支持情况。
二、JOIN 放大或丢失行：连接顺序决定聚合口径
当查询涉及多张表时，聚合结果翻倍或者变小，通常是 JOIN 发生在一对多关系上。先举一个翻倍的例子：订单主表 orders 存有订单编号和下单金额，订单明细表 order_items 存有每个订单下的商品行。如果想统计每个客户的总下单金额，直接把 orders 和 order_items 连接后对 orders.amount 求和，就会出现重复计算。
原因是一对多连接会让 orders 表中的同一行出现多次，每多一个明细行，订单金额就重复累加一次。正确方案有两种：一是先把明细表按订单号聚合，再与主表连接；二是在连接前对明细表做 GROUP BY，避免重复。下面是对比示例：
-- 错误写法：直接 JOIN 后 SUM 主表金额，金额被放大
SELECT o.customer_id, SUM(o.amount) AS total_amount
FROM orders o
JOIN order_items i ON o.order_id = i.order_id
GROUP BY o.customer_id;
-- 正确写法：先聚合明细表，再连接主表
SELECT o.customer_id, SUM(o.amount) AS total_amount
FROM orders o
JOIN (
SELECT order_id, SUM(item_amount) AS item_total
FROM order_items
GROUP BY order_id
) i ON o.order_id = i.order_id
GROUP BY o.customer_id;
还要注意 LEFT JOIN 带来的 NULL 问题。如果使用 LEFT JOIN 连接明细表，未匹配的明细行会补 NULL，此时 COUNT(i.order_id) 会忽略这些 NULL，但 SUM(o.amount) 仍然会计算主表金额。分析数据完整性时，应分别统计主表行数和关联成功的行数，避免把两种口径混在一起。
三、WHERE 与 HAVING 的过滤时机不同
聚合结果不正确时，很多人会去检查 WHERE 条件，但往往忽略了 HAVING 的作用范围。SQL 的标准执行顺序是先根据 WHERE 过滤原始行，再执行 GROUP BY 分组，然后进行聚合计算，最后才用 HAVING 过滤聚合后的分组。如果把聚合条件写进 WHERE，数据库会报错，或者因为过滤对象不对而得到错误结果。
例如需要查询总销售额超过 10000 的部门，正确写法是 SELECT dept_id, SUM(amount) AS total FROM sales GROUP BY dept_id HAVING SUM(amount) > 10000;。如果写成 WHERE SUM(amount) > 10000，标准 SQL 不允许在 WHERE 中使用聚合函数，会直接报语法错误。但有些数据库或工具链可能不会明确报错，导致排查方向偏离。
-- 正确写法：分组后再过滤聚合结果 SELECT dept_id, SUM(amount) AS total_amount FROM sales GROUP BY dept_id HAVING SUM(amount) > 10000; -- 错误写法：WHERE 中引用聚合函数，多数数据库会报错 SELECT dept_id, SUM(amount) AS total_amount FROM sales WHERE SUM(amount) > 10000 GROUP BY dept_id;
还有一种情况是 WHERE 条件本身过滤掉了某些分组，导致结果看起来少了数据。比如在统计月均订单数时，如果先 WHERE status = 'completed'，再按月份分组，得到的是已完成订单的月均数；如果想同时统计所有订单并计算完成率，应该把状态判断放进聚合函数中，例如 SUM(CASE WHEN status = 'completed' THEN 1 ELSE 0 END)。
四、浮点精度与数据类型转换导致的误差
聚合结果出现类似 0.30000000000000004 的值，或者 AVG 返回整数而丢失小数，通常与列的数据类型有关。浮点类型 FLOAT 和 REAL 使用二进制近似存储十进制小数，累加时误差会累积。对于需要精确计算的金额、库存数量，应使用 DECIMAL 或 NUMERIC 类型，并在聚合后控制精度。
整数除法是另一个常见陷阱。在 SQL Server 中，两个整数相除会返回整数，小数部分被截断，导致 AVG 的结果比预期小。例如 SELECT AVG(score) FROM exam; 如果 score 是整型，返回的可能是整数。解决方法是显式转换：SELECT AVG(CAST(score AS DECIMAL(10,2))) FROM exam;。MySQL 的行为不同，整数除整数会返回小数，但跨数据库迁移时需要留意这种差异。
-- 整数类型直接求平均可能丢失精度 SELECT AVG(score) AS avg_score_old FROM exam; -- 显式转换后精度保留 SELECT AVG(CAST(score AS DECIMAL(10,2))) AS avg_score_new FROM exam; -- 比较浮点数时避免直接使用等号 SELECT SUM(amount) AS total_amount FROM orders WHERE ABS(SUM(amount) - 1000.00) < 0.01;
另外，隐式类型转换也会造成聚合偏差。比如字符串类型的数字列在 SUM 时可能按字符串排序规则处理，或者出现非数值字符导致转换失败。建议在表设计阶段就为数值字段选择合适类型，查询时避免混用不同类型进行比较。对于已经出现的精度误差，可以使用 ROUND、CAST 或调整数据库参数来控制显示和存储精度。
五、小结：按执行顺序逐步排查
聚合结果不对时，建议按以下顺序检查：先确认聚合列是否存在 NULL，并明确 COUNT(column) 和 COUNT(*) 的口径；再检查多表连接是否造成一对多重复；然后确认 WHERE 和 HAVING 是否用错；最后看数据类型和精度。这个顺序对应 SQL 的逻辑执行流程，能覆盖大多数业务场景。
排查时可以借助小范围数据验证。先取出少量明确结果的数据，手动计算聚合值，再与查询结果对比。如果差异来自 JOIN，把连接前后的行数分别统计；如果差异来自 NULL，用 IS NULL 查看分布；如果差异来自精度，检查字段类型。把这些基础检查做成清单，遇到问题就能快速定位，而不是盲改查询。