直接写多个CASE WHEN会统计错行数，因为其逐行计算且无分组逻辑，导致同一行被重复计入多列；必须配合GROUP BY明确分组维度，并在每组内用CASE WHEN过滤后聚合。
为什么直接写多个CASE WHEN会统计错行数
因为 CASE WHEN 是逐行计算的表达式，不是分组逻辑本身。如果你在 SELECT 里写多个 CASE WHEN 却没配对 GROUP BY，结果会出现「同一行被同时计入多个统计列」，看起来总数对不上。真正起作用的是后续的聚合函数（如 COUNT、SUM）和分组维度。
- 错误写法：
SELECT COUNT(CASE WHEN status='paid' THEN 1 END), COUNT(CASE WHEN status='refunded' THEN 1 END) FROM orders;—— 这能算出总支付数和总退款数，但无法区分「按用户」或「按日期」的交叉分布 - 正确前提：必须明确「按什么分组」，再在每组内用
CASE WHEN做条件过滤后聚合 - 常见坑：把
CASE WHEN写在WHERE里试图“先筛选再分组”，这会丢掉其他条件的原始行，导致分组基数变小
如何用CASE WHEN + GROUP BY做多维条件计数
核心是让每个 CASE WHEN 返回一个可聚合的标量（如 1 / 0、金额、分类标签），再套一层 SUM 或 COUNT。注意：用 COUNT 时 NULL 不计数，所以 ELSE NULL 是安全的；用 SUM 则常配合 THEN 1 ELSE 0。
- 统计各城市中「已支付订单数」「未支付订单数」「平均订单金额」：
SELECT city, COUNT(CASE WHEN status = 'paid' THEN 1 END) AS paid_count, COUNT(CASE WHEN status != 'paid' THEN 1 END) AS unpaid_count, AVG(CASE WHEN status = 'paid' THEN amount END) AS avg_paid_amount FROM orders GROUP BY city;
-
AVG(...)里的CASE WHEN返回NULL时会被自动忽略，不影响均值计算 - 不要写
COUNT(*) FILTER (WHERE status='paid')—— 这是 PostgreSQL 特有语法，MySQL 和 SQL Server 不支持
嵌套CASE WHEN处理优先级与区间分段
当条件有重叠或需要排序判断（比如「金额500为高」），必须用嵌套或按顺序写的 CASE WHEN，因为执行是自上而下匹配第一个成立分支。
- 错误顺序（高区间写前面）：
CASE WHEN amount > 100 THEN 'high' WHEN amount > 500 THEN 'very_high' ...→ 后者永远不触发 - 正确写法（从高到低或用 AND 显式限定）：
CASE WHEN amount > 500 THEN 'very_high' WHEN amount > 100 THEN 'high' ELSE 'low' END AS amount_level
- 避免在
CASE中重复计算复杂表达式，可先用子查询或 CTE 提取中间字段，尤其涉及函数（如DATE_FORMAT(created_at, '%Y-%m')）
性能和可读性容易被忽略的点
CASE WHEN 本身不索引友好，但如果条件列（如 status）上有索引，且写法简单（无函数包裹），优化器仍可能利用索引快速定位行。真正拖慢的是在 CASE 内部调用函数、子查询或类型转换。
- 慢：
CASE WHEN UPPER(status) = 'PAID' THEN ...→ 破坏status索引使用 - 快：
CASE WHEN status = 'paid' THEN ...（假设存储是小写） - 大表慎用多个长
CASE WHEN+ 聚合：考虑是否可拆成多个带WHERE的单统计查询，再用UNION ALL合并，有时反而更快 - 别名尽量见名知义，比如不用
c1、c2，而用active_user_count、churned_user_count
实际写的时候，先画个表格列出「分组维度」「每个统计项的逻辑条件」「输出类型（计数/求和/均值/分类）」，再逐项翻译成 CASE WHEN，比边写边改更省时间。
