用CASE WHEN替代多WHERE子查询可提升分组统计效率，需置于SELECT或GROUP BY中而非WHERE；统计用SUM(CASE...ELSE 0)更安全；注意边界定义、NULL处理、索引友好及执行计划验证。
用 CASE WHEN 替代多张 WHERE 子查询做分组统计
直接在 GROUP BY 里嵌套多个 CASE WHEN，比写多个带 WHERE 的子查询或 UNION ALL 更简洁、执行更高效。数据库只需扫描一次表，避免重复 I/O 和临时表开销。
常见错误是把 CASE WHEN 写在 WHERE 里试图“过滤分组”，结果要么语法报错（如 PostgreSQL 不允许 WHERE 中用聚合列），要么逻辑错位——CASE WHEN 在聚合前做分类，必须放在 SELECT 或 GROUP BY 中。
- 分组维度是动态的（比如按价格区间+地域组合），就用
CASE WHEN构造虚拟分组字段 - 想在同一行输出多个统计口径（如“订单数”“有效订单数”“退款订单数”），每个用独立
SUM(CASE WHEN ... THEN 1 ELSE 0 END) - MySQL 8.0+ 和 PostgreSQL 支持在
GROUP BY中直接用列别名，但 SQL Server 和旧版 MySQL 需重复写整个CASE WHEN表达式
避免 NULL 值干扰 COUNT 和 SUM 的统计逻辑
COUNT() 会忽略 NULL，SUM() 同样跳过 NULL，但新手常误以为 COUNT(CASE WHEN ...) 能直接计数——其实它数的是非 NULL 行，而 CASE WHEN 没有 ELSE 时默认返回 NULL，导致漏统计。
正确写法永远显式补 ELSE 0（对 SUM）或 ELSE NULL（对 COUNT，但更推荐统一用 SUM 避免歧义）：
SELECT region, SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) AS paid_cnt, SUM(CASE WHEN status = 'refunded' THEN 1 ELSE 0 END) AS refunded_cnt, COUNT(*) AS total_cnt FROM orders GROUP BY region;
- 别用
COUNT(CASE WHEN status='paid' THEN 1 END)：没匹配的行返回NULL，被COUNT忽略，结果偏小 - 数值型统计一律优先用
SUM(CASE ... THEN 1 ELSE 0 END)，语义清晰且不怕NULL - 如果要统计满足条件的某字段非空值个数（如
user_id），才用COUNT(CASE WHEN ... THEN user_id END)
嵌套 CASE WHEN 处理优先级与边界重叠
多维度交叉分组时（例如“高价值新客”“低价值老客”），容易因条件顺序或区间重叠导致同一行被归入多个或零个分组。必须明确优先级，并用 BETWEEN 或 AND 严格定义边界。
典型陷阱：价格分段写成 WHEN price ，结果 <code>price=80 同时命中两个分支——CASE WHEN 是从上到下匹配第一个真值，所以顺序即优先级。
- 区间判断务必降序排列（如先
>= 500，再>= 100），或用BETWEEN显式限定闭区间 - 字符串分组注意大小写和空格，
TRIM(UPPER(channel))预处理比在CASE里反复写函数更高效 - PostgreSQL 中可配合
COALESCE处理NULL分组值：COALESCE(CASE WHEN ... END, 'unknown')
性能敏感场景下避免在 CASE WHEN 中调用函数
在 CASE WHEN 条件中写 DATE_PART('year', order_time) 或 LOWER(name)，会导致无法使用索引，全表扫描概率大增。尤其当表行数超百万时，响应时间可能从毫秒级跳到秒级。
优化核心原则：把运行时计算提到 WHERE 过滤或生成列（generated column）中，让 CASE WHEN 只做简单比较。
- 提前在
WHERE中过滤掉无关数据（如WHERE order_time >= '2024-01-01'），缩小CASE处理集 - MySQL 5.7+ / PostgreSQL 12+ 支持函数索引，可对
EXTRACT(YEAR FROM order_time)建索引 - 高频使用的分组逻辑，考虑建计算列（如
order_year INT AS (YEAR(order_time)) STORED），然后CASE WHEN order_year = 2024
复杂业务规则往往需要多层 CASE 组合，但每加一层都放大表达式求值开销。上线前务必用 EXPLAIN 看执行计划，确认是否走了索引、是否产生临时表——这些细节不验证，统计结果再准也没用。
