必须前置三类校验：先比行数发现分组偏差，再用LEFT JOIN比内容定位差异，最后反查原始数据验逻辑语义；任一环节异常都需立即中止后续分析。
直接结论：别信聚合结果本身，先用三类校验交叉比对——行数、内容、逻辑语义。 你看到的 COUNT(*) 或 AVG(grade) 数值再“整齐”，也可能掩盖 NULL 合并、JOIN 膨胀、字段未分组等底层问题。验证不是补救，是必须前置的动作。
查行数是否一致：秒级发现大偏差
分组后行数不对，后面全白算。比如按 city 分组，理论上全国有 691 个地级市，但 SELECT COUNT(*) FROM (SELECT city FROM orders GROUP BY city) t 返回 628 —— 那就说明至少 63 个城市的 city 值被合并了（空格、大小写、NULL 或类型隐式转换）。
- 快速校验脚本：
SELECT (SELECT COUNT(*) FROM (SELECT shop_id FROM sales_2024 GROUP BY shop_id) a) AS src_cnt, (SELECT COUNT(*) FROM (SELECT store_id FROM fact_sales GROUP BY store_id) b) AS tgt_cnt;
- 如果两边行数不等，立刻停手，不要往下跑
EXCEPT或明细比对 —— 根本不在同一维度上 - 注意：MySQL 8.0+ 中
COUNT(DISTINCT city)和(SELECT COUNT(*) FROM (SELECT city FROM t GROUP BY city) t)结果可能不同，因为前者跳过 NULL，后者把 NULL 当作一组
比内容是否完全匹配：用 LEFT JOIN 而不是 EXCEPT
EXCEPT 看起来干净，但它自动去重、不保留重复行、MySQL 原生不支持，且无法区分“左边多”还是“右边少”。真实校验要能定位到哪一行、哪个分组键出了问题。
- 正确写法是双 CTE +
LEFT JOIN，ON必须包含所有分组字段：SELECT a.category, a.region, a.cnt AS cnt_2023, b.cnt AS cnt_2024 FROM (SELECT category, region, COUNT(*) AS cnt FROM orders_2023 GROUP BY category, region) a LEFT JOIN (SELECT category, region, COUNT(*) AS cnt FROM orders_2024 GROUP BY category, region) b ON a.category = b.category AND a.region = b.region WHERE b.cnt IS NULL OR a.cnt != b.cnt;
-
WHERE b.cnt IS NULL找出 2023 有但 2024 完全缺失的组合；a.cnt != b.cnt抓出数量变化（含 NULL 比较失效风险） - 若分组字段可能为
NULL，ON条件要改写为：COALESCE(a.category, '') = COALESCE(b.category, '')，否则NULL = NULL不成立，导致全量误判为“缺失”
验逻辑语义是否合理：从原始数据反推聚合条件
聚合值对不上，大概率不是函数算错了，而是参与计算的数据集本身就不对。比如 AVG(grade) 是 72，但人工抽查发现很多 95 分以上的学生没进统计 —— 很可能是 WHERE status = 'completed' 过滤掉了未完成记录，而业务方默认所有学生都该计入。
- 必须执行这三步反查：
-- 1. 原始筛选结果有多少行？ SELECT COUNT(*) FROM student WHERE status = 'completed'; <p>-- 2. 分组前抽样看 grade 是否真有 NULL 或异常值？ SELECT grade, COUNT(*) FROM student WHERE status = 'completed' GROUP BY grade ORDER BY grade DESC LIMIT 5;</p><p>-- 3. 聚合字段是否被 JOIN 意外复制？例如： SELECT s.sno, COUNT(<em>) FROM student s JOIN score sc ON s.sno = sc.sno GROUP BY s.sno ORDER BY COUNT(</em>) DESC LIMIT 3;
如果某sno对应几十条score记录，那AVG(grade)就被严重稀释了 -
HAVING只能过滤聚合后结果，不能替代WHERE做原始行筛选；想筛“订单金额为负的用户”，写WHERE amount 再 <code>GROUP BY user_id，别写HAVING SUM(amount) —— 后者会漏掉单笔负、其余正的用户
最常被跳过的一步是检查分组字段本身的值分布：用 SELECT category, COUNT(*) FROM t GROUP BY category ORDER BY COUNT(*) DESC 看一眼，往往就能发现 “‘北京 ’（带空格）” 和 “‘北京’” 被分成了两组，或者大量 NULL 被悄无声息地聚成了一行“未知”。不看原始分布，只盯着聚合数字调，等于蒙眼修表。
