COUNT(*)在LEFT JOIN后永不为0，因其统计连接后全部行数（含右表NULL行）；判零须用COUNT(右表主键)，因它忽略NULL值。
COUNT(*) 在 LEFT JOIN 后永远不为 0，这是语义决定的，不是 bug
LEFT JOIN 的核心行为是：左表每行必保留，右表没匹配上就补 NULL 行。所以 COUNT(*) 统计的是“连接后结果集的总行数”，哪怕右表全空，左表有 100 行，结果就是 100 —— 它根本不会暴露“右表为空”这个事实。
为什么 COUNT(右表主键) 才能判空
关键在 NULL 处理逻辑：COUNT(列) 只统计该列非 NULL 的值，而 COUNT(*) 统计所有行（含 NULL 行）。
-
COUNT(*)→ 数的是左表行数（无论右表是否匹配） -
COUNT(o.id)→ 只数右表成功关联的行，没匹配时o.id是 NULL，不计入 - 用
COUNT(o.id) = 0判断“无订单用户”，比o.id IS NULL更可靠（避免被 WHERE 提前过滤）
LEFT JOIN 后加 WHERE 条件会悄悄干掉空分组
常见错误：在 LEFT JOIN 后写 WHERE o.status = 'paid'。这会导致右表没匹配或 status 不是 'paid' 的左表行全部消失——LEFT JOIN 变相退化成 INNER JOIN。
- 正确做法：把右表筛选条件移到
ON子句里，如LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 如果必须用 WHERE，得配合
OR o.status IS NULL，但语义混乱且难维护 - 某些老版本 MySQL 对
HAVING COUNT(o.id) = 0支持不稳定，建议优先用CASE WHEN或子查询显式表达意图
大数据量下直接 COUNT(*) + LEFT JOIN 容易 OOM
当右表存在一对多关系（比如一个用户对应上千条日志），JOIN 中间结果集可能爆炸式膨胀，COUNT(*) 虽轻量，但数据库仍需物化整个中间集，内存和 IO 压力陡增。
- 更稳的解法：用子查询或 CTE 预聚合右表，例如
(SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) o再 LEFT JOIN - 若只需判断“有/无”，用
EXISTS比LEFT JOIN + COUNT更快，尤其右表无索引时 -
COUNT(o.id)看似简单，但如果o.id没索引，优化器可能放弃使用索引驱动，导致全表扫描
真正麻烦的从来不是语法，而是你默认 COUNT(*) 就该反映“业务意义上的数量”——它只忠于 SQL 标准里的行计数语义，不替你理解“用户数”“订单数”“有效关联数”之间的差异。
