COUNT() 返回0而非NULL，因其统计非NULL行数，LEFT JOIN未匹配时右表字段全为NULL，COUNT(右表列)结果为0；需用COALESCE或IS NULL判空缺。
LEFT JOIN 后 COUNT() 为什么总是 0 而不是 NULL？
因为 COUNT() 统计的是非 NULL 行数，哪怕 LEFT JOIN 没匹配上，它也会把右表的空行当成“0 行”来算，结果就是 COUNT(右表.id) 返回 0，而不是你想要的“该分组缺失”的标识。想看出空缺，得用 COUNT(右表.某非空列) 配合 COALESCE 或直接判 IS NULL。
常见错误现象：
– 明明左表有 12 个月，但报表只显示 8 行数据
– 分组后某月销量为 0，但该月根本没出现在结果里
– 用 COUNT(*) 时，空缺分组反而被统计成 1（因左表行存在）
- 正确做法：用
COUNT(右表.order_id)，不是COUNT(*) - 若要显式标出空缺，加
COALESCE(COUNT(右表.order_id), 0) - 若需过滤出真正空缺的分组，WHERE 右表主键
IS NULL（注意别写成= NULL）
如何生成完整时间维度（如连续12个月）再 LEFT JOIN？
数据库本身不自带“补全月份”功能，得手动构造一个含全部时间点的临时表或 CTE，否则 LEFT JOIN 的“左”侧只有实际存在的数据，根本没法驱动补空。
使用场景：
– 月度销售报表要求显示 1~12 月，哪怕某月零订单
– 用户活跃度按周统计，需覆盖全年 52 周
- PostgreSQL / SQL Server：用
GENERATE_SERIES()或VALUES构造月份数字 - MySQL 8.0+：用递归 CTE，例如
WITH RECURSIVE months AS (...) - MySQL 5.7：靠已有数字表或 JOIN 多次
SELECT 1 UNION SELECT 2 ... - 关键点：构造的维度表必须有能和业务表关联的字段（如
year_month），且类型一致
LEFT JOIN 补空后 SUM() / AVG() 出现意外 NULL 怎么办？
SUM() 和 AVG() 遇到全 NULL 输入时返回 NULL，不是 0 或 0.0 —— 这和 COUNT() 的行为完全不同，容易在报表里造成数值断裂或前端报错。
性能影响：
– COALESCE(SUM(...), 0) 不影响执行计划，但会掩盖真实空值语义
– 若后续还要做除法（如转化率），先判分母是否为 0 比硬塞 0 更安全
- 推荐写法：
COALESCE(SUM(右表.amount), 0) - 避免写法：
IFNULL(SUM(...), 0)（MySQL 特有，可读性差） - 特别注意：
AVG()在空组中返回 NULL，且不会跳过 NULL 值——它只忽略右表中该字段为 NULL 的行，不是忽略整个分组
为什么 GROUP BY 字段不能只写左表，还得包含右表的非聚合字段？
SQL 标准要求：SELECT 列表中所有非聚合字段，必须出现在 GROUP BY 中。如果 LEFT JOIN 后引用了右表字段（比如 右表.status），又没把它放进 GROUP BY，多数数据库（如 MySQL 严格模式、PostgreSQL）会直接报错 column must appear in the GROUP BY clause。
容易踩的坑：
– 开发环境关了 MySQL 的 sql_mode=ONLY_FULL_GROUP_BY，上线后炸了
– 以为 “反正右表是空的，字段肯定 NULL，不用管”，结果一匹配上就出错
- 安全做法：GROUP BY 左表主键 + 所有参与 JOIN 或 SELECT 的右表字段
- 更优做法：把右表字段也聚合掉，比如用
MAX(右表.status)（前提是业务允许） - 别依赖隐式分组——它不可移植，且逻辑模糊
最麻烦的不是写不出补空逻辑，而是补完发现指标口径和业务对不上：比如把“未下单”和“下单但金额为 0”混作一谈。这类问题没法靠 SQL 自动识别，得提前和产品确认空值背后的业务含义。
