直接套用CASE WHEN做多维聚合会漏数据，因为CASE WHEN本身不产生分组，仅逐行计算；必须配合GROUP BY和SUM/COUNT等聚合函数（如SUM(CASE WHEN...THEN 1 ELSE 0 END)）才能实现条件分流与汇总，否则返回原始行数、值错位或NULL干扰。
为什么直接套用CASE WHEN做多维聚合会漏数据
因为 CASE WHEN 本身不产生分组，如果没配合 GROUP BY 或聚合函数，它只是逐行计算表达式，不会自动折叠维度。常见错误是写了一堆 CASE WHEN 字段却忘了加 GROUP BY，结果返回原始行数，聚合值全是重复或错位的。
真正起作用的是「CASE WHEN + 聚合函数」组合，比如 SUM(CASE WHEN ... THEN 1 ELSE 0 END)，本质是把条件逻辑“塞进”聚合函数内部，让数据库在分组过程中按条件分流累加。
- 必须搭配
SUM、COUNT、AVG等聚合函数使用，单独CASE WHEN不聚合 - 所有非聚合字段（如地区、月份）都得出现在
GROUP BY中，否则报错或结果不可靠 -
ELSE 0（或ELSE NULL）强烈建议显式写出，避免NULL干扰SUM/COUNT计算
如何用一个SELECT同时算出多个条件指标
典型场景：一张订单表，要按 region 和 order_month 统计「总单量」「高单价订单数」「退款率」「平均客单价」——四个指标维度不同、条件不同，但想一次查完。
正确写法是每个指标独立写一个 CASE WHEN 套聚合函数，全部放在同一 SELECT 中：
SELECT region, order_month, COUNT(*) AS total_orders, SUM(CASE WHEN amount > 500 THEN 1 ELSE 0 END) AS high_value_cnt, AVG(CASE WHEN is_refunded = 1 THEN 1.0 ELSE 0.0 END) AS refund_rate, AVG(CASE WHEN amount > 0 THEN amount END) AS avg_order_amount FROM orders GROUP BY region, order_month;
注意第三行：AVG(CASE WHEN is_refunded = 1 THEN 1.0 ELSE 0.0 END) 计算的是退款占比（不是次数），因为 AVG 对 0/1 序列等价于 SUM / COUNT；而最后一行用 CASE WHEN amount > 0 THEN amount END 且不写 ELSE，会让 AVG 自动忽略 NULL，更安全。
CASE WHEN嵌套和性能隐患怎么避
两层以上 CASE WHEN 嵌套（比如「按金额分档再按地区打折」）可读性差，且部分数据库（如 MySQL 5.7、早期 PostgreSQL）对嵌套深度有隐式限制，还可能让优化器放弃使用索引。
- 优先拆成多个独立
CASE WHEN字段，比嵌套更易调试、更易被优化器识别 - 避免在
CASE WHEN中调用函数（如CASE WHEN YEAR(order_time) = 2023...），会导致字段无法走索引；应提前在WHERE过滤或用生成列 - 如果条件分支超 5 个，考虑用
LEFT JOIN关联维度表（如状态码映射表），比长串CASE更易维护
NULL值和类型不一致导致的静默错误
最常被忽略的坑：当 CASE WHEN 分支返回不同类型（如字符串和数字），数据库会隐式转换，可能截断、四舍五入或报错。例如 CASE WHEN flag=1 THEN 'Y' ELSE 0 END 在 PostgreSQL 中直接报错，在 MySQL 中转成字符串后数值计算失效。
另一个坑是忘记处理原始字段的 NULL：比如统计「有效用户数」写成 COUNT(CASE WHEN last_login > '2023-01-01' THEN user_id END)，如果 user_id 本身为 NULL，这一行就算满足条件也不会被计入——因为 COUNT 只统计非 NULL 值。
- 所有
CASE WHEN分支确保返回同类型，统一用CAST(... AS ...)显式转换 - 统计数量优先用
SUM(CASE ... THEN 1 ELSE 0 END)，比COUNT(CASE ... THEN x END)更可控 - 涉及除法（如转化率）务必用
NULLIF(denominator, 0)防止除零，否则某些数据库（如 Redshift）会直接报错中断查询
CASE WHEN 就会从利器变成陷阱。 
