先交代一个多数人踩过的坑：CASE WHEN 本身不生成行，只做列内判断。如果你某个分组没匹配到任何 WHEN 分支，结果就是 NULL，然后你可能会误以为“该组合不存在”——其实只是逻辑没写全。这种情况在分类字段有空值、大小写不统一、或者隐式类型转换时特别容易发生。
具体怎么做？这里有三个实操要点：
- 所有
CASE WHEN必须带上ELSE 0（或者ELSE NULL，但要明确意图），否则意外的NULL会直接影响聚合结果。 - 先跑一条
SELECT DISTINCT category FROM table看清实际数据长什么样，别凭直觉写WHEN 'Active'却发现数据库里存的是'active'甚至'ACTIVE '。 - 字符串比较之前套一层
TRIM(UPPER())，尤其是源数据来自 Excel 或日志导入时，这一步几乎不可或缺。
为什么直接用 CASE WHEN 写透视表容易漏数据
问题出在 CASE WHEN 的底层逻辑上——它不负责造数据，只对已有行做判断。某组只要没命中任何一个 WHEN 分支，结果就是 NULL，而聚合函数在遇到 NULL 时处理方式各有不同，不是你想的那样。
举一个典型场景：统计各地区高价值客户（金额 ≥ 5000）与普通客户数量。
SELECT region, SUM(CASE WHEN amount >= 5000 THEN 1 ELSE 0 END) AS high_value_cnt, SUM(CASE WHEN amount < 5000 THEN 1 ELSE 0 END) AS regular_cntFROM ordersGROUP BY region;
注意 ELSE 0 不可省略。如果省掉，SUM 会把未命中的行当作 NULL，结果就是那一行完全不参与求和——这不是你想要的。
这里有个容易混淆的知识点：COUNT() 默认跳过 NULL，所以 COUNT(CASE WHEN ...) 和 SUM(CASE WHEN ... THEN 1 ELSE 0 END) 的行为完全不同——前者只统计命中分支的行数，后者统计所有行并按条件加权。多数透视场景需要的是后者。
嵌套 CASE WHEN 在多级分类中的写法陷阱
当你需要按「状态 + 时间段」联合分类时，比如“已支付且本周下单”“已支付且上周下单”，很容易堆出一长串 AND 条件：
CASE WHEN status = 'paid' AND created_at >= ... THEN ...
这种写法的隐患在于：一旦某个条件字段含 NULL，整条判断就成了 UNKNOWN，分支根本不触发。更稳妥的做法是分层判断：
SELECT SUM(CASE WHEN status = 'paid' THEN CASE WHEN created_at >= CURRENT_DATE - INTERVAL '7 days' THEN 1 WHEN created_at >= CURRENT_DATE - INTERVAL '14 days' THEN 1 ELSE 0 END ELSE 0 END) AS paid_last14days
核心原则有两个：外层 WHEN 先过滤主维度（比如 status），减少内层计算量；每层 CASE 都配上 ELSE，阻断 NULL 的传导。另外，时间函数依赖数据库方言，这里用的是 PostgreSQL 的 INTERVAL 写法，MySQL 需要换成 DATE_SUB(NOW(), INTERVAL 7 DAY)。
GROUP BY 与 CASE WHEN 列名冲突导致的报错
常见错误信息是 column "xxx" must appear in the GROUP BY clause。这个错误的典型场景是：你在 SELECT 里用 CASE WHEN 定义了一个别名，又在 GROUP BY 里试图引用这个别名——但 SQL 标准要求 GROUP BY 必须基于原始字段或完整表达式，别名是无效的。
解决办法只有两个：
- 在
GROUP BY中完整重复一遍CASE WHEN表达式。这种做法最稳妥，兼容所有数据库。 - 用子查询或 CTE 先把分类列算好，外层再
GROUP BY别名。可读性好，但部分旧版 MySQL 不支持 CTE。
举个例子：
SELECT region_type, COUNT(*)FROM ( SELECT CASE WHEN population > 1000000 THEN 'big' ELSE 'small' END AS region_type FROM cities) tGROUP BY region_type;
这种结构绕开了表达式重复，也避免了字段名歧义。不过需要留意，CTE 在 SQLite 中不可用，这时得用子查询代替。
