COUNT()配JOIN后总数变多是因为JOIN将主表每行与关联表匹配的多行展开，COUNT()统计的是连接后的行数而非主表原始行数；必须搭配GROUP BY才能按主表分组统计条件计数，否则结果无意义。
为什么COUNT(*)配JOIN后总数变多了
因为JOIN会把主表每行和关联表匹配的多行展开，再用COUNT(*)就数的是“连接后的行数”，不是主表原始行数。比如用户表10行，每人有3条订单，LEFT JOIN后变成30行，COUNT(*)就是30——这通常不是你想要的。
COUNT(CASE WHEN ...)必须搭配GROUP BY才能按主表分组统计
想算“每个用户有多少个已支付订单”，就得先按用户分组，再在每组内用CASE WHEN筛条件、COUNT计数。漏掉GROUP BY会导致整张结果只返回一行，且数值无意义。
-
COUNT是聚合函数，不GROUP BY就默认全表为一组 -
CASE WHEN order_status = 'paid' THEN 1 END中，不满足条件时返回NULL，而COUNT会自动忽略NULL，等价于只计满足条件的行 - 别写
COUNT(1)或COUNT(*)在里面——那会把整组都算进去，失去条件过滤作用
LEFT JOIN + COUNT(CASE WHEN ...)的典型写法
以查用户数、每人已支付订单数、未支付订单数为例：
SELECT u.user_id, u.name, COUNT(CASE WHEN o.status = 'paid' THEN 1 END) AS paid_count, COUNT(CASE WHEN o.status = 'pending' THEN 1 END) AS pending_count FROM users u LEFT JOIN orders o ON u.user_id = o.user_id GROUP BY u.user_id, u.name;
注意点：
- 用
LEFT JOIN确保没订单的用户也出现在结果里（paid_count和pending_count为0） -
GROUP BY必须包含SELECT中所有非聚合字段，否则多数数据库报错（如PostgreSQL、MySQL严格模式） - 如果只想要有订单的用户，改用
INNER JOIN，但此时没订单的用户直接被过滤掉，不会出现在结果中
替代方案：用子查询或CTE会更清晰但性能可能下降
当条件逻辑复杂（比如嵌套判断、涉及多个关联表字段），硬塞进CASE WHEN会让SQL难以维护。这时可考虑：
- 用
COALESCE(SUM(CASE ...), 0)代替COUNT——语义更明确，且能显式处理NULL - 把条件统计拆成独立子查询或CTE，再JOIN回来，可读性高，但要注意关联键重复导致的笛卡尔积风险
- 某些场景下，
SUM(CASE WHEN ... THEN 1 ELSE 0 END)比COUNT更直观，且行为完全一致
实际执行时，优化器通常能将COUNT(CASE)和SUM(CASE)生成相同执行计划，不必过度纠结选哪个，重点是别漏GROUP BY、别错用JOIN类型。
