LEFT JOIN 后空值不显示是因为聚合函数（如COUNT）忽略NULL，且未显式保留左表主键；应使用COALESCE(COUNT(右表字段),0)并确保GROUP BY仅含左表字段。
LEFT JOIN 后 GROUP BY 为什么空值不显示？
因为 LEFT JOIN 的左表记录还在，但右表没匹配上时，右表字段全为 NULL；一旦你对右表字段做 GROUP BY 或聚合（比如 COUNT()、SUM()），这些 NULL 行在分组结果里就“看不见”了——不是被过滤，而是聚合函数把它们算成 0 或空，再配合 SELECT 列没显式保留左表主键，导致你以为数据丢了。
关键点：分组填充空位，核心是「保持左表结构完整」+「用聚合兜底右表缺失值」。
- 先用
LEFT JOIN把基准维度（如日期、分类、ID）拉全，确保每行都存在 - 聚合函数必须作用在右表字段上，且用
COALESCE()或IFNULL()显式转成默认值（比如0或'-'） - 不要在
WHERE里过滤右表字段（例如WHERE t2.status = 'done'），这会把NULL行干掉，等价于退化成INNER JOIN
怎么写才能让缺失分组自动补 0？
典型场景：统计每天订单数，但某几天没订单，结果里直接跳过——这不是数据少，是聚合逻辑没兜住空档。
正确做法是把「日期维度」单独拎出来当左表（可生成连续日期序列），再 LEFT JOIN 订单表，最后用 COUNT(t2.order_id) 而不是 COUNT(*)：
SELECT d.date, COALESCE(COUNT(t2.order_id), 0) AS order_cnt FROM date_series d LEFT JOIN orders t2 ON d.date = DATE(t2.created_at) GROUP BY d.date;
-
COUNT(t2.order_id)只统计非NULL值，没匹配上的自然得 0 -
COUNT(*)会统计左表每一行，哪怕右表是NULL也算 1，结果全变成 1 - MySQL 8.0+ 可用
SEQUENCE或递归 CTE 生成date_series；旧版本常用日历表或UNION ALL拼接
GROUP BY 字段混用左右表列会踩什么坑？
常见错误：在 SELECT 和 GROUP BY 里同时写左表 id 和右表 name，结果分组崩了，或者某些行莫名消失。
根本原因：SQL 标准要求 GROUP BY 必须覆盖所有非聚合列；而右表字段在 LEFT JOIN 中可能为 NULL，多个 NULL 在分组时是否合并，不同数据库行为不一致（PostgreSQL 严格合并，MySQL 5.7 默认不合并）。
- 只按左表字段
GROUP BY，右表字段一律走聚合（MAX(t2.name)、STRING_AGG(t2.tag)等） - 如果真要按右表字段分组，先用
COALESCE(t2.category, 'unknown')把NULL转成确定值，再GROUP BY - MySQL 5.7 开启
ONLY_FULL_GROUP_BY后，混用会直接报错：Expression #2 of SELECT list is not in GROUP BY clause
性能差是不是 LEFT JOIN 搞的鬼？
是。尤其是右表没索引、或左表维度太大（比如百万级用户 × 千级商品 = 十亿级笛卡尔预备量）时，LEFT JOIN 本身就会慢，后面再 GROUP BY 更卡。
优化方向不是砍逻辑，而是控制连接基数：
- 右表务必在
JOIN条件字段建索引（如orders(created_at)、sales(product_id)） - 左表如果是宽泛维度（如全量用户），先用子查询或 CTE 过滤出实际需要的范围（比如最近 30 天活跃用户）
- 避免在
ON条件里写函数（如ON d.date = DATE(t2.created_at)），MySQL 无法用上created_at索引；改成t2.created_at >= d.date AND t2.created_at
真正难的从来不是写出能跑的 SQL，而是想清楚：哪部分必须靠 JOIN 拉齐，哪部分其实可以前置聚合再关联——空位填充看着是语法问题，根子上是数据建模和查询路径的选择。
