LEFT JOIN 必须在 GROUP BY 之前执行，否则右表未匹配行会被过滤；正确顺序为 FROM ... LEFT JOIN ... GROUP BY ...，且右表字段需加入 GROUP BY 或用聚合函数处理，COUNT() 返回0表示无匹配而非数据丢失。
GROUP BY 和 LEFT JOIN 顺序写反了，数据就“丢”在连接里
LEFT JOIN 必须在 GROUP BY 之前完成，否则右表未匹配行会被直接过滤掉——不是数据库删了数据，而是你让聚合先发生，再连接，逻辑上就断掉了补空的基础。
典型错误写法：SELECT ... FROM left_table GROUP BY ... LEFT JOIN right_table ...。这句 SQL 在绝大多数数据库（MySQL、PostgreSQL）中甚至无法执行，会报语法错误；即便某些引擎允许，结果也完全不可控，因为 GROUP BY 已经把原始行压缩成组，LEFT JOIN 失去了作用对象。
正确顺序永远是：FROM left_table LEFT JOIN right_table ON ... GROUP BY ...。只有先完成连接，左表的每一行才带着右表可能为 NULL 的字段进入分组阶段，后续才能用 COALESCE(SUM(...), 0) 或 COUNT(right_table.id) = 0 判定空缺。
LEFT JOIN 后 GROUP BY 漏掉右表字段，导致聚合结果错乱
如果 SELECT 中引用了右表字段（比如 right_table.status），又没把它放进 GROUP BY，MySQL 8.0+（开启 ONLY_FULL_GROUP_BY）或 PostgreSQL 会直接报错：column "right_table.status" must appear in the GROUP BY clause。
这不是 bug，是 SQL 标准要求：非聚合列必须明确属于哪个分组键。常见应对方式有：
- 把右表字段加进
GROUP BY—— 但要注意，这会让分组粒度变细，可能多出你不想要的组合行 - 用聚合函数包裹右表字段，如
MAX(right_table.status)—— 仅当该字段在组内实际一致时才安全 - 改用
COALESCE(MIN(right_table.status), 'N/A')配合判空逻辑，避免因 NULL 导致整个字段被忽略
分组后 COUNT() 返回 0 却误以为“数据丢了”
COUNT() 统计的是非 NULL 行数，不是“是否存在”。LEFT JOIN 未匹配时，右表所有字段都是 NULL，COUNT(right_table.id) 自然返回 0 —— 这恰恰说明“该分组右表无数据”，不是丢失，是正确结果。
真正要警惕的是以下几种情况：
-
COUNT(*)返回 1：说明左表有行，但右表为空，容易被当成“有数据”而忽略空缺 -
SUM(right_table.amount)返回NULL：和COUNT()行为不同，得用COALESCE(SUM(...), 0)显式转 0 - 想筛选“完全没右表数据”的分组，条件必须写
WHERE right_table.id IS NULL，不能写= NULL
想补全月份/日期但 GROUP BY 没驱动源，空缺永远补不上
数据库不会自动帮你生成“本该存在但没数据”的时间点。如果你的左表只含 2026-01 到 2026-03 的记录，LEFT JOIN 再怎么写，也不可能驱动出 2026-04 的行。
必须手动构造完整时间维度：
- 用 CTE 构造连续日期：
WITH months AS (SELECT '2026-01' AS mon UNION SELECT '2026-02' UNION ...) - 用递归 CTE（MySQL 8.0+/PostgreSQL）生成范围：
SELECT DATE_ADD('2026-01-01', INTERVAL n MONTH) AS dt FROM ... - 从日历表或数字辅助表 JOIN，确保“驱动侧”包含全部目标分组值
没这一步，所有后续的 LEFT JOIN 和 COALESCE 都只是在已有数据上修修补补，补不了根本缺失的分组行。
