LEFT JOIN 后 COUNT(*) 总是非零，因它统计结果集总行数，左表每行必保留（无匹配则补NULL行）；要统计右表实际匹配数，须用 COUNT(右表非空字段)。
LEFT JOIN 后 COUNT(*) 为什么总是非零？
因为 COUNT(*) 统计的是 JOIN 后结果集的总行数，不是“右表匹配成功数”。LEFT JOIN 保证左表每行都保留，哪怕右表没匹配上，也会补一行 NULL 字段——这行仍被 COUNT(*) 计入。
常见现象：查“每个用户订单数”，结果全是 1，哪怕很多用户根本没下单。这不是 bug，是语义使然。
- 要统计“实际有几笔订单”，必须用
COUNT(orders.id)或COUNT(orders.order_no)——前提是该字段定义为NOT NULL -
COUNT(orders.id)在无匹配时值为NULL，COUNT自动跳过，结果就是 0 - 别用
COUNT(1)替代，它和COUNT(*)在 LEFT JOIN 中行为完全一致，无法判空
INNER JOIN 后 COUNT 统计为何突然变大？
本质是笛卡尔积膨胀：当左表某行匹配右表多行（比如 1 个用户对应 5 条订单），JOIN 后就生成 5 行；再 GROUP BY 前不做预处理，COUNT(*) 就会把这 5 行全算进去。
实操建议：
- 先用
SELECT COUNT(*)和SELECT COUNT(DISTINCT users.id)对比——如果前者远大于后者，说明中间结果已膨胀 - 避免在
ON条件里写OR或函数（如UPPER(orders.status)），否则索引失效，匹配更慢、更不准 - 若只需数量不要明细，优先用子查询预聚合：
(SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) o，再 LEFT JOIN 这个结果
WHERE 条件放错位置导致统计归零
在 LEFT JOIN 后写 WHERE orders.status = 'paid'，会把所有没订单或订单状态不为 'paid' 的左表行全部过滤掉——LEFT JOIN 彻底退化成 INNER JOIN。
正确做法：
- 右表筛选条件必须放进
ON子句：LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'paid' - 如果业务逻辑真需要后置过滤（比如还要查未支付但存在订单的用户），得显式保留空行：
WHERE orders.status = 'paid' OR orders.status IS NULL，但语义易混淆，慎用 -
HAVING COUNT(orders.id) = 0在部分老版本 MySQL 中支持不稳定，不如用CASE WHEN COUNT(orders.id) = 0 THEN 1 ELSE 0 END显式表达
GROUP BY 字段选错让 COUNT 失效
多表 JOIN 后，GROUP BY 必须用主表字段（如 users.id），不能跨表用从表字段（如 orders.created_at）。否则优化器可能放弃索引分组，性能断崖下跌，甚至返回错误结果。
关键细节：
-
GROUP BY字段必须和SELECT中非聚合字段完全一致，且带表前缀（如users.id，不能只写id） - 联合索引要覆盖
ON条件字段 +GROUP BY字段，顺序按 JOIN 顺序排，例如orders(user_id, status) - 用
EXPLAIN看type是否为ALL或index，key_len是否接近索引总长度——否则索引没被充分利用
真正麻烦的不是写不出 COUNT，而是默认它该等于“业务数量”——SQL 只忠于行计数规则，不替你区分“用户数”“有效订单数”“关联事件数”。字段选错、条件放错、NULL 处理漏掉，任何一个点都会让统计结果偏离真实业务含义。
