LEFT JOIN 后 COUNT(*) 永远不为零，因为其统计包含左表每行及右表匹配失败时补的 NULL 行；应改用 COUNT(右表非空字段) 或 CASE WHEN 判定是否存在数据。
LEFT JOIN 后 COUNT(*) 为什么永远不为零
因为 COUNT(*) 统计的是行数，哪怕右表没匹配到，LEFT JOIN 也会补一行 NULL 值，这行依然被算进去了。真正该用的是 COUNT(右表主键) 或 COUNT(右表非空字段)，它会忽略 NULL，没数据时结果才是 0。
常见错误现象：
写成 SELECT ..., COUNT(*) FROM A LEFT JOIN B ON ... GROUP BY A.id，发现所有分组的计数都 ≥1，根本筛不出“空分组”。
- 正确做法：用
COUNT(B.id)（假设B.id是右表主键，JOIN 失败时为NULL） - 别用
COUNT(*)、COUNT(1)或COUNT(A.id)—— 它们都不反映右表是否存在数据 - 如果右表可能有重复关联（比如一对多），
COUNT(B.id)统计的是匹配行数，不是“是否有数据”，这时更稳妥的是CASE WHEN B.id IS NOT NULL THEN 1 ELSE 0 END配合MAX()或SUM()
WHERE 条件写在 ON 还是 WHERE？空分组会被意外过滤掉
LEFT JOIN 的右表筛选条件如果错放 WHERE，会导致本该保留的左表空分组被干掉——因为 WHERE B.status = 'active' 会把所有 B.status 为 NULL 的行（即没匹配上的）直接踢出结果集。
使用场景：你想查“所有用户及其活跃订单数”，但又不想漏掉那些压根没下过单的用户。
- 右表的过滤条件必须写在
ON子句里，例如：LEFT JOIN orders B ON A.id = B.user_id AND B.status = 'active' -
WHERE只放左表条件，比如WHERE A.created_at > '2024-01-01' - 如果已经写在
WHERE里了，执行后发现空分组没了，八成就是这个原因
用 COALESCE 或 CASE 判零更安全，别依赖 COUNT 结果直比较
有些数据库（比如老版本 MySQL）对 GROUP BY 和 NULL 的处理边界模糊，直接写 HAVING COUNT(B.id) = 0 在某些复杂查询里可能行为不稳定；而且语义上，“计数为 0” 不如 “右表无记录” 来得明确。
- 推荐写法：
HAVING MAX(CASE WHEN B.id IS NOT NULL THEN 1 ELSE 0 END) = 0 - 或者更直白：
HAVING COUNT(B.id) = 0可以用，但务必确认你用的是COUNT(B.id)，不是COUNT(*) - 如果还要在 SELECT 里显示“有/无数据”，用
COALESCE(MAX(CASE WHEN B.id IS NOT NULL THEN 'yes' END), 'no')比嵌套判断更可靠
性能提示：COUNT(B.id) 不一定走索引，注意执行计划
COUNT(B.id) 看似轻量，但如果 B.id 没索引，或数据库优化器没选对驱动表，可能触发全表扫描。特别是右表很大、左表很小的时候，效率可能比预想中差很多。
- 检查执行计划，重点看
Extra字段有没有Using join buffer或Using temporary - 确保
ON条件里的右表关联字段（如B.user_id）有索引 - 如果只是要“是否存在”，用
EXISTS子查询有时比LEFT JOIN + COUNT更快，尤其当右表数据稀疏时
空分组逻辑看着简单，但 JOIN 类型、COUNT 对象、WHERE 位置、索引覆盖这四点只要错一个，结果就静悄悄地不对了。
