90%“丢数据”实为LEFT JOIN+GROUP BY误用：非聚合字段未入GROUP BY致结果错乱；COUNT(*)与COUNT(字段)语义不同；补全维度需左表含全量值；SUM/AVG全NULL返回NULL而非0。
分组后“丢数据”，90%不是真丢了，而是 LEFT JOIN + GROUP BY 的组合没写对——它根本不会报错，但结果会悄悄跳过空分组、错配字段、甚至把 NULL 当 0 算。
GROUP BY 字段必须和 SELECT 中非聚合列严格一致
MySQL（尤其开启 ONLY_FULL_GROUP_BY）会直接报错，但关掉后它就“自作主张”选一个值填充，比如你写：
SELECT a.date, b.store_name, SUM(a.amount) FROM orders a LEFT JOIN stores b ON a.store_id = b.id GROUP BY a.date;
这里 b.store_name 没进 GROUP BY，也不在聚合函数里。MySQL 可能随机挑某一行的 store_name 返回，看起来像“丢”了其他门店数据。
- 正确做法：所有非聚合字段都放进
GROUP BY，例如GROUP BY a.date, b.store_name - 如果
b.store_name是 NULL（LEFT JOIN 未匹配），这一行仍会被分到一个分组里，但名字是 NULL —— 这不是丢，是如实反映关联失败 - 别依赖
ANY_VALUE()绕过检查，它掩盖问题，不解决语义歧义
COUNT() 返回 0 不等于“该分组存在且为空”，而可能是“根本没这条左表记录”
用 LEFT JOIN 补全维度时，常误以为 COUNT(b.id) 为 0 就代表“这个日期+门店有记录但没订单”。其实不是：
-
COUNT(b.id)统计的是右表非 NULL 的id行数；没匹配上时b.id是 NULL，所以 COUNT 结果为 0 - 但如果你写的是
COUNT(*)，它会算左表那一行本身（即使右表全 NULL），结果变成 1 —— 这就彻底混淆了“有门店无订单”和“门店根本不存在”的区别 - 真正要识别“空缺”，得靠
WHERE b.id IS NULL，而不是看 COUNT 值
想补全缺失分组（比如补全所有月份），LEFT JOIN 的“左表”必须含全量时间点
很多人写：
SELECT m.month, COUNT(o.id) cnt FROM (SELECT '2026-01' AS month UNION ... ) m LEFT JOIN orders o ON DATE_FORMAT(o.ctime, '%Y-%m') = m.month GROUP BY m.month;
看着没问题，但漏了一点：如果子查询 m 没生成全部月份（比如少写了 2026-04），那 4 月就永远不会出现在结果里 —— LEFT JOIN 只能从“左”出发驱动补全，不能凭空造数据。
- 构造全量维度必须显式、完整，推荐用 CTE 或临时表生成连续时间序列
- 别指望原订单表里
GROUP BY MONTH(ctime)后再 LEFT JOIN 能补出空月，因为那张“左表”本身就没有空月 -
COALESCE(COUNT(o.id), 0)在这里多余，COUNT 本来就不会返回 NULL
SUM()/AVG() 遇到全 NULL 分组返回 NULL，不是 0
这是和 COUNT() 最容易混淆的一点。当你对某组做 SUM(amount)，而该组所有 amount 都是 NULL（或右表完全没匹配），结果是 NULL，不是 0。
- 前端渲染或后续计算（如转化率 = paid_cnt / total_cnt）遇到 NULL 分母会直接崩，不是除零错误，而是类型不匹配
- 安全写法是：
COALESCE(SUM(o.amount), 0)，但注意：这改的是值，不是语义——它把“无数据”伪装成“有数据且为 0” - 更严谨的做法是保留 NULL，并在业务层区分“未发生”和“发生但为零”
真正的难点不在语法，而在你得先想清楚：你补的到底是“维度空缺”，还是“事实空缺”，或是“统计口径空缺”。三者用同一套 SQL 写法，结果一定错。
