COUNT(CASE WHEN)比嵌套子查询更实用，因单次扫描即可并行统计多个条件，避免多次全表扫描；必须显式写ELSE（或依赖隐式NULL），否则未匹配行被COUNT忽略导致计数偏小，推荐优先用SUM(CASE WHEN THEN 1 ELSE 0 END)确保语义清晰、结果稳健。
为什么 COUNT(CASE WHEN) 比嵌套子查询更实用
因为单次扫描就能完成多个分组条件的计数，避免多次全表扫描或 JOIN，尤其在大表上性能差异明显。MySQL、PostgreSQL、SQL Server 都支持，但注意 CASE WHEN 必须有 ELSE（或隐式为 NULL），否则漏匹配行会导致计数偏小。
常见错误现象：COUNT(CASE WHEN status = 'paid' THEN 1) 得到的总数小于实际行数——这是因为没写 ELSE NULL，而 COUNT() 会忽略 NULL，但缺省 ELSE 时未命中条件的行被当作 NULL 处理，结果看似“少算”，其实是逻辑正确但不符合预期。正确写法必须显式覆盖所有分支意图：
COUNT(CASE WHEN status = 'paid' THEN 1 ELSE NULL END)
或者更简洁地利用 COUNT 自身特性（它只统计非 NULL）：
COUNT(CASE WHEN status = 'paid' THEN 1 END)
COUNT(CASE WHEN) 与 SUM(CASE WHEN) 的关键区别
两者都能实现条件计数，但语义和容错性不同：
-
COUNT(CASE WHEN ... THEN 1 END)：只统计「满足条件且表达式结果非 NULL」的行数；若THEN返回NULL或条件不成立，该行不计入 -
SUM(CASE WHEN ... THEN 1 ELSE 0 END)：强制每行贡献 0 或 1，总和即满足条件的行数；即使漏写ELSE，多数数据库会报错或警告，反而更容易暴露逻辑缺陷
推荐优先用 SUM 写法，因为：
- 语义更直白：“把每个匹配记 1 分，不匹配记 0 分，加起来就是总数”
- 避免因忘记
ELSE NULL导致的静默偏差 - 方便扩展为加权统计（例如
THEN order_amount）
示例：统计不同状态订单数及总金额
SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) AS paid_count,<br>SUM(CASE WHEN status = 'paid' THEN order_amount ELSE 0 END) AS paid_amount
多条件组合时如何避免逻辑重叠或遗漏
当需要按多个正交维度分别计数（比如「已支付且发货」、「已支付未发货」、「未支付」），不能简单堆砌多个独立 CASE，而要确保条件互斥、穷尽：
- 用
WHEN ... THEN从高优先级到低优先级排列，一旦命中即终止判断（CASE是顺序匹配） - 最后务必加
ELSE覆盖兜底情况，哪怕只是ELSE 0 - 对「多选一」场景，直接用单个
CASE输出分类标签再GROUP BY更清晰；对「多维并行统计」，才用多个并列SUM(CASE...)
反例（条件重叠）：SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) 和 SUM(CASE WHEN shipped = true THEN 1 ELSE 0 END) —— 这是两个独立维度，没问题；
但若写成：SUM(CASE WHEN status = 'paid' AND shipped = true THEN 1 ... 与 WHEN status = 'paid' THEN 1... 就会产生重复计数。
在 GROUP BY 场景下 COUNT(CASE WHEN) 的典型误用
最常被忽略的是：当外层有 GROUP BY 时，CASE WHEN 内部引用的字段必须属于分组键或被聚合，否则会报错（如 PostgreSQL 的 “column must appear in the GROUP BY clause”）。解决方式只有两种：
- 把
CASE中用到的所有列都加入GROUP BY（不推荐，可能破坏分组粒度） - 确保
CASE只依赖分组键字段，或使用聚合函数包裹（例如MAX(status)）——但这通常意味着原始需求设计有问题
正确做法是先明确分组意图。例如按用户统计各类订单数：
SELECT user_id,<br> SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) AS paid_orders,<br> SUM(CASE WHEN status = 'refunded' THEN 1 ELSE 0 END) AS refunded_orders<br>FROM orders<br>GROUP BY user_id;
这里 status 不在 GROUP BY 中，但被包裹在聚合内，语法合法且语义清晰。
真正容易卡住的地方在于嵌套层级变深时——比如在窗口函数里再套 CASE，或与 FILTER（PostgreSQL 特有）混用。这时候别硬扛，先拆成 CTE 或临时聚合，可读性和调试成本反而更低。
