1. 核心语法拆解：先搞清楚CASE WHEN的执行逻辑再动手

1.1 两种写法的适用差异

PostgreSQL里的CASE WHEN有两种形态，很多初学者一开始容易混在一起。第一种叫简单CASE，写法是CASE后面跟着一个表达式，WHEN后面是值：

SELECT status, CASE status WHEN 0 THEN '待处理' WHEN 1 THEN '已受理' WHEN 2 THEN '已办结' ELSE '未知状态' END AS status_text FROM work_order;

第二种叫搜索CASE，WHEN后面直接跟完整的条件表达式，这也是实际中使用频率最高的：

SELECT duration, CASE WHEN duration < 60 THEN '不足1小时' WHEN duration < 480 THEN '1小时内' WHEN duration < 1440 THEN '1天内' ELSE '超过1天' END AS duration_level FROM task_record;

简单CASE适合判断一个字段的离散值，写法更紧凑；搜索CASE适合范围判断、多字段联合判断这类场景。两种写法的执行逻辑本质相同，只是一个用等值比较，一个用完整条件表达式。

判断顺序上，CASE语句是自上而下逐条匹配的，只要第一条命中了就立刻返回结果，后面的分支不再参与判断。这意味着你把更具体的条件放在前面、更宽泛的条件放在后面，结果才是符合预期的。搜索CASE尤其要注意这一点，因为条件的先后直接决定结果归属。

1.2 ELSE分支到底要不要写

先说结论：除非你非常确定所有分支都能被覆盖，否则建议保留ELSE。CASE语句在没有ELSE的情况下，如果所有WHEN都不命中，返回值是NULL。这个NULL很容易引发连锁问题，比如你把它做加减乘除、拼进字符串、或者JOIN到别的表，都会出现让人摸不着头脑的结果。

有一次我处理一批订单数据时，需要给订单打上“大额”“普通”的标签，条件就两个：金额大于等于10000标“大额”，小于10000标“普通”。看起来全覆盖了，于是有同事省略了ELSE。结果后面数据里混进了一批金额为NULL的订单，这些订单全部变成了NULL标签，后续统计里这批订单就“消失”了。排查了很久才发现，根源就是NULL值的订单没有被任何WHEN捕获，ELSE的缺失让NULL悄悄蔓延到了下游。

所以我的建议是：没有十足的把握就写ELSE，实在不想写也至少保证有兜底逻辑。尤其是处理外部分析系统、数据接口传过来的数据时，字段里出现NULL是常态，不明来源的异常值是常态，ELSE这个兜底是最后一道防线。

1.3 一个容易被忽略的细节：WHEN分支的表达式求值顺序

CASE的短路行为还体现在表达式求值上。一旦某个WHEN条件满足，PostgreSQL会直接返回对应的THEN结果，后续分支里的表达式不会再被计算。这可以用来规避一些潜在的错误。

比如你想要计算一个除法，但被除数可能为0，你可以这么写：

SELECT CASE WHEN total_count = 0 THEN 0 ELSE success_count / total_count END AS success_rate FROM biz_stats;

这里当total_count为0时，直接返回0，不会进入ELSE部分，自然也不会触发除以0的错误。这个技巧在报表统计中使用频率很高。凡是可能出错的表达式，都优先放在靠后的分支里，让它在条件被跳过时不参与计算。

另外CASE表达式支持多个THEN返回不同类型，但实际使用中要控制住。返回类型不一致时，PostgreSQL会尝试做隐式转换，转换不了就直接报错。比如一个分支返回字符串，另一个分支返回数字，这种写法在绝大多数情况下是不被允许的，即使建表时没报错，查询执行时也会报错。保持分支返回值类型一致是最稳妥的做法。

2. 高频应用场景：从统计聚合到行转列，一套写法吃透

2.1 用CASE WHEN做条件聚合，一张表统计多个维度

CASE WHEN在聚合函数里的用法，是我个人觉得性价比最高的技巧。常见场景是：一张明细表，你需要同时统计多个业务状态的数量、金额，或者按不同口径拆成绩效看板。

普通思路是多次查询再合并，实际上一条SQL配合条件聚合就可以搞定：

SELECT department_id, COUNT(*) AS total_order_count, COUNT(*) FILTER (WHERE status = 0) AS pending_count, SUM(CASE WHEN amount >= 10000 THEN 1 ELSE 0 END) AS large_amount_count, SUM(CASE WHEN pay_time IS NOT NULL THEN 1 ELSE 0 END) AS paid_count, COALESCE(SUM(CASE WHEN status = 2 THEN amount ELSE 0 END), 0) AS completed_amount FROM order_list WHERE create_time >= now() - interval '7 days' GROUP BY department_id ORDER BY total_order_count DESC;

这里的技巧是：SUM(CASE WHEN ... THEN 1 ELSE 0 END)相当于“计数满足条件的数据行”，而COUNT(*) FILTER (WHERE ...)是PostgreSQL的专用语法，效果类似但语义更清晰。两个写法都支持，我一般优先用FILTER，因为它只关注过滤条件，不需要像CASE那样特意构造0和1。

如果你还要统计满足条件的金额总和、平均值，CASE WHEN几乎是唯一顺手的选择。因为FILTER只负责计数，SUM(CASE WHEN ... THEN amount END)可以直接聚合出对应金额。注意这里我没有写ELSE 0，原因是金额金额字段本身不会是负数，表达式里未命中的分支返回NULL，而SUM会自动忽略NULL，结果等价于0。但如果你需要区分“没有满足条件记录”和“满足条件但金额为0”这两种情况，就不能这么做，否则会混淆NULL和0。

2.2 经典行转列：把明细数据变成宽表报表

行转列是CASE WHEN最出名的应用场景。假设有一张每个销售每天的业绩表，你想把不同日期的业绩展示在同一行，形成每个销售一条记录、各天各自一列的报表形式：

SELECT sales_name, MAX(CASE WHEN stat_date = '2025-01-01' THEN daily_amount ELSE 0 END) AS day01, MAX(CASE WHEN stat_date = '2025-01-02' THEN daily_amount ELSE 0 END) AS day02, MAX(CASE WHEN stat_date = '2025-01-03' THEN daily_amount ELSE 0 END) AS day03 FROM sales_daily WHERE stat_date BETWEEN '2025-01-01' AND '2025-01-03' GROUP BY sales_name;

为什么这里用MAX配合CASE？因为还按sales_name分组后，每个销售仍然可能对应多行数据，你要做的是把符合条件的那个值取出来放到对应列，MAX可以让同一分组内没有命中的行返回ELSE定义的值、命中的行返回真实值。

行转列适合固定的列数场景。如果有动态生成列的需求，即报表中的日期是变动的，就要用SQL动态拼接的方式来实现，把需要转列的日期遍历出来，拼成一条完整的SQL再执行。这种做法的场景通常是在报表工具或程序里实现，不适合放在数据库的存储过程里硬写。

2.3 在UPDATE语句里用CASE WHEN批量修正数据

CASE WHEN除了用在SELECT，也经常配合UPDATE来批量修正数据。比如线上有个表的历史数据中，某个字段的值因历史迁移错位了，需要按不同条件做不同修正：

UPDATE product_info SET price = CASE WHEN price IS NULL THEN default_price WHEN price < 1 AND category = 'sample' THEN 1 ELSE price END, updated_at = now() WHERE id IN (SELECT id FROM temp_correct_list);

这里的关键逻辑是，每行记录执行自己的条件判断，按不同情况写入不同的值。这样一次UPDATE可以代替多条UPDATE语句，减少事务次数和锁持有的时间。对于线上核心表来说，这个改进在性能上意义很大。

另外要注意UPDATE里CASE WHEN的ELSE分支，如果你的某个条件分支不满足时希望保留原值，ELSE必须写原字段名，而不能不写ELSE就让其变成NULL。

我在一家公司处理账单表时，曾经因为漏掉ELSE分支，把一批本不该更新的行的字段直接置为了NULL，后续补救了两天才恢复完整数据。这个教训让我以后写批量UPDATE时都会习惯逐条检查每个分支的覆盖范围。

3. ORDER BY排序与CASE嵌套：让排序规则和业务逻辑对齐

3.1 自定义排序规则，把业务优先级写进ORDER BY

很多业务里数据需要按业务层级排序，比如工单优先处理级别、客户等级、事件紧急程度。如果只用字段本身的字典序或者创建时间排序，无法体现业务优先级。

CASE WHEN放在ORDER BY里，可以完美解决这个问题：

SELECT order_no, pay_status, create_time FROM trade_order WHERE date_trunc('day', create_time) = CURRENT_DATE ORDER BY CASE WHEN pay_status = 1 THEN 1 WHEN pay_status = 2 THEN 0 WHEN pay_status = 3 THEN 2 ELSE 3 END, create_time DESC;

这里的排序结果是：已支付（状态2）优先展示，未支付（状态1）其次，支付失败（状态3）再次，其他情况垫底。每个分组内部再按创建时间倒序。这个方法在待处理工单页面、客服后台列表、风控审核列表这类场景里很实用，一行CASE WHEN就能把业务顺序和SQL排序对齐。

同理，你也可以在ORDER BY里用CASE WHEN把一个字段映射成数值后再排序，比如按客户等级把“VIP”“普通”“潜在”映射成数字1、2、3。排序规则建议写在SQL层面而不是程序里，因为数据库里的排序可以直接利用索引，程序排序则要全部捞回来再排，数据量一大差距就出来了。

3.2 嵌套CASE的三种写法对比

业务条件复杂时，嵌套CASE不可避免。嵌套写法有三种典型形式。

第一种是完全嵌套，即THEN后面再跟一个CASE：

SELECT CASE WHEN score >= 90 THEN CASE WHEN score >= 95 THEN 'A+' ELSE 'A' END WHEN score >= 80 THEN 'B' ELSE 'C' END AS grade FROM student_score;

第二种是扁平化，把条件拆成多个细分分支：

SELECT CASE WHEN score >= 95 THEN 'A+' WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' ELSE 'C' END AS grade FROM student_score;

第三种是把条件组合在同一个WHEN里：

SELECT CASE WHEN score >= 90 AND perfect_rate >= 0.95 THEN 'A+' WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' ELSE 'C' END AS grade FROM student_score;

我一般优先选扁平化写法，主要是因为逻辑更清晰、调试更直观。嵌套CASE一旦超过两层，阅读成本会飙升，而且容易出现WHERE分支覆盖顺序的bug。如果逻辑实在复杂，也可以考虑先在子查询里用两次CASE分别计算不同的标量，再在外部对结果做判断。这样每个CASE的职责单一，排查时只需定位一层。

3.3 一个踩坑示例：嵌套时分支顺序颠倒的隐蔽问题

有一次同事写了一段类似下面的嵌套CASE，用于把“用户年龄区间+会员等级”映射为“分层标签”：

SELECT CASE WHEN age < 30 THEN CASE WHEN member_level >= 3 THEN '年轻高价值用户' ELSE '年轻普通用户' END WHEN age >= 30 AND age < 60 THEN CASE WHEN member_level >= 3 THEN '中年高价值用户' ELSE '中年普通用户' END ELSE '老年用户' END AS user_label FROM user_profile;

看起来清晰明了，但实际跑出来的结果中，“年轻高价值用户”的人数明显偏少。排查后发现，原因不是CASE写错了，而是age字段本身存在NULL值，且NULL比较的结果是NULL，所有WHEN条件都不成立，这批用户全部落到了ELSE分支的“老年用户”里。

这个问题的教训在于：当表里有NULL字段时，嵌套CASE的每个外层分支都应该先判断NULL或者在最前面加一个ELSE条件。类似“age >= 30 AND age < 60”这类范围判断无法捕获NULL值。我在处理类似的用户分层逻辑时，会先加上一个“WHEN age IS NULL THEN '未知'”的兜底分支，再进入年龄判断。逻辑多了几个字，但结果可预期得多。

4. 多字段组合与性能优化：CASE WHEN不是简单堆条件

4.1 多字段联合条件，用布尔逻辑做条件编排

业务需求经常是多个字段联合判定，比如判断一笔订单是否属于“高优先级用户的高额订单”。多个条件都可以放在一个WHEN里，用AND、OR、NOT连接：

SELECT order_no, CASE WHEN vip_level >= 3 AND order_amount >= 5000 AND is_abnormal = 0 THEN '重点优质单' WHEN vip_level >= 3 OR order_amount >= 5000 THEN '潜力优质单' ELSE '普通单' END AS quality_label FROM trade_order WHERE is_deleted = 0;

这个场景的要点是优先级顺序：最严格的条件在前，最宽松的条件在后。如果把“潜力优质单”的分支放在前面，那么“重点优质单”永远匹配不到，因为满足VIP>=3或金额>=5000的记录在第一个分支就已经全部被捕获了。

多字段联合判断时，还要注意PostgreSQL对于三值逻辑的处理。WHERE中只保留了满足条件（结果为TRUE）的行，但WHEN的分支判断也是同样的逻辑，只有结果为TRUE才会进入分支。所以如果一个WHEN表达式中AND的两边任何一个为NULL，整个表达式就不是TRUE，条件不成立，分支被跳过。

4.2 条件判断里的NULL处理三板斧

针对NULL，我总结了三板斧的处理方式。

第一板斧：每次写CASE分支前，心里快速过一遍可能为NULL的字段。按字段上一轮的取值情况判断是否可能NULL，这是经验，但大多数宕数据都是从某个字段NULL开始的。

第二板斧：使用COALESCE或NULLIF配合CASE做兜底。比如：

SELECT CASE WHEN COALESCE(score, 0) >= 60 THEN '及格' ELSE '不及格' END AS pass_label FROM exam_record;

这里把NULL先转成0再比较，避免了NULL判断的陷阱。

第三板斧：直接在WHERE里排除NULL行的场景，把NULL行单独过滤出来。这适合你本身不需要参与判断活动数据的情况。

SELECT CASE WHEN score >= 60 THEN '及格' ELSE '不及格' END AS pass_label, score FROM exam_record WHERE score IS NOT NULL;

注意COALESCE和NULLIF都不会改变原字段值，如果在CASE表达式中使用它们，原字段仍然保留原始值。两者都是纯运算函数，不影响后续的统计结果。

4.3 表达式索引：让CASE WHEN在WHERE里提速

在WHERE子句里使用CASE WHEN时，很容易遇到查询变慢的情况。原因很简单，普通B-tree索引基于原字段的值构建，而CASE WHEN通常会改造字段值，索引无法被直接用于条件过滤。

解决问题的方法是创建表达式索引。比如查询中经常出现“根据打折后的价格筛选低价商品”这类逻辑：

SELECT product_id, CASE WHEN is_discount = 1 THEN price * 0.8 ELSE price END AS real_price FROM product_sku WHERE CASE WHEN is_discount = 1 THEN price * 0.8 ELSE price END < 500;

这个查询每次都会对每一行计算一次表达式，再过滤结果。数据量到50万以后，响应就会变得很慢。解决办法是建一个表达式索引：

CREATE INDEX idx_product_sku_real_price ON product_sku ( (CASE WHEN is_discount = 1 THEN price * 0.8 ELSE price END) );

这样查询可以走索引快速找到符合条件的行。这个优化特别适合固定查询模式的场景。如果CASE表达式参数不固定，比如打折比例每次传入的值都不一样，表达式索引就无法命中，因为索引是对固定表达式构建的。

另外注意创建表达式索引时，表达式要和你查询中的表达式保持一致，包括CASE的缩进、括号、ELSE值都不能差。PostgreSQL会按字面匹配表达式来判断是否命中索引。

4.4 当CASE WHEN遇上GROUP BY时的性能取舍

CASE WHEN与GROUP BY结合时，GROUP BY本身会先聚合，聚合后CASE的结果一般是最终结果。但如果CASE里含有聚合函数，逻辑就会复杂许多，也容易出现慢查询。

比如你想统计每一类标签的数量，可以这样写：

SELECT CASE WHEN order_amount >= 10000 THEN '大额单' WHEN order_amount >= 5000 THEN '中等单' ELSE '普通单' END AS amount_level, COUNT(*) AS cnt FROM trade_order WHERE create_time >= now() - interval '3 months' GROUP BY CASE WHEN order_amount >= 10000 THEN '大额单' WHEN order_amount >= 5000 THEN '中等单' ELSE '普通单' END;

注意GROUP BY后面的表达式和SELECT里的CASE是同一个表达式，而不是一个别名。PostgreSQL在GROUP BY阶段会按表达式本身来分组，别名不一定被允许引用。在PostgreSQL中，GROUP BY可以引用SELECT列表中的别名，但某些情况下语法比较严格。所以最安全的方式是直接写表达式。

如果这个查询的命中行数大，而且你经常要这个统计结果，可以考虑建一个基于相同表达式的索引来加速GROUP BY的分组过程。表达式索引除了能被WHERE使用，也能在GROUP BY和ORDER BY中被用来加速排序和分组。

5. 工程化实践与常见问题：CASE WHEN从“会写”到“写好”

5.1 常见错误速查表

我把自己几年间在项目中遇到过的CASE相关报错和坑整理成了一个速查表，方便直接对照排查。

遇到过最多的问题是返回类型不一致。比如CASE分支里THEN 0和THEN '无数据'混用，这种写法在PostgreSQL里通常会执行时直接报错。建议建表时或者写SQL前就想好每个分支的数据类型。如果确实需要把数字显示为字符串，可以用CAST显式转换，让数据库引擎帮你在返回值上做统一的类型转换。

5.2 CASE WHEN与子查询的取舍：什么时候不该用CASE

CASE WHEN虽然强大，但不适合承担过于复杂的业务计算。比如一个分支里要查另一个表的数据，你可以写子查询，但性能往往会差。还有一种情况是分支逻辑里需要多次扫描同一张表，这时候用CASE嵌套子查询会让执行计划变得非常昂贵且难追踪。

我处理过一个业务：需要根据用户的最近一次登录时间、最近一次消费时间、累计消费金额三个维度判断用户价值等级。最初别人写的SQL里把三个维度的查询都塞进了CASE的THEN里，导致一次查询子查询扫描了三次用户流水表，执行时间高达十几秒。

优化方法是先在一个子查询里把最近登录时间、最近消费时间、累计消费金额计算出来，再在外层用CASE做纯条件判断：

WITH user_metric AS ( SELECT user_id, MAX(login_time) AS last_login_time, MAX(pay_time) AS last_pay_time, SUM(amount) AS total_amount FROM user_behavior_log GROUP BY user_id ) SELECT user_id, CASE WHEN last_login_time >= now() - interval '7 days' AND last_pay_time >= now() - interval '30 days' AND total_amount >= 10000 THEN '高价值活跃用户' WHEN last_login_time >= now() - interval '30 days' THEN '活跃用户' WHEN total_amount >= 5000 THEN '高消费低活跃用户' ELSE '普通用户' END AS user_tag FROM user_metric;

CASE的定位是“分支判断”，而不是“延迟计算”。一旦分支里需要做聚合运算、多表关联、开窗函数，就应该先通过子查询或CTE把数据准备好，再让CASE用已经准备好的字段做纯条件映射。这个设计习惯能让SQL保持清晰，也会让执行计划更稳定。

5.3 与LATERAL、窗口函数配合的进阶玩法

CASE WHEN和窗口函数搭配也很常见。比如按金额排序时，你想优先展示“重点用户”的单子，可以在ROW_NUMBER()的ORDER BY中嵌入CASE：

SELECT order_no, user_id, order_amount, ROW_NUMBER() OVER ( PARTITION BY user_id ORDER BY CASE WHEN is_star_user = 1 THEN 0 ELSE 1 END, order_amount DESC ) AS user_order_rank FROM trade_order WHERE date_trunc('month', create_time) = CURRENT_DATE;

这个写法的效果是：每个用户内部，星标用户的订单排前面，非星标用户的订单排后面，组内再按金额倒序。实际应用场景常见于电商运营页面，把核心用户的重点订单优先展示。

CASE与LATERAL配合也很实用。LATERAL可以让你在子查询里引用外层表的字段，然后在子查询里做若干条件判断，再返回多个列。比如：

SELECT o.order_no, t.level_name, t.handle_days FROM trade_order o CROSS JOIN LATERAL ( SELECT CASE WHEN o.amount >= 10000 AND o.freight = 0 THEN '高级订单' WHEN o.amount >= 5000 THEN '中级订单' ELSE '普通订单' END AS level_name, CASE WHEN o.amount >= 10000 THEN 1 WHEN o.amount >= 5000 THEN 2 ELSE 3 END AS handle_days ) t;

这种写法适合CASE计算结果被多个外层列引用的情况。LATERAL子查询把判断逻辑单独封装，外层代码不重复写CASE，避免了一处改动需要同步多处的问题。我一般会把较复杂的CASE逻辑封装在LATERAL或CTE里，方便后续调试。

5.4 ORM与SQL中CASE WHEN的取舍建议

很多用ORM框架写业务逻辑的同事喜欢把分支判断写到Java或Python代码里，但遇到批量数据转换时，代码里逐行判断会有两个明显问题：第一，查询会把可能需要的所有数据全量拉回应用层，网络和内存开销大；第二，应用层逐行遍历再操作，性能比SQL里直接完成差两三个数量级。

什么时候适合在SQL里用CASE WHEN，什么时候不适合，我的判断标准是数据处理的位置。如果属于“数据报表、统计查询、批量加工”，直接在SQL里用CASE WHEN；如果属于“复杂的业务规则流程、需要多渠道获取更多信息才能决策”，留在应用层处理更合理，毕竟SQL层的判断条件和应用层的事务逻辑混在一起会很难维护。

举个例子，一个微信公众号消息推送业务，要根据用户的积分、注册天数、订单偏好选择不同的推送文案，这种规则未来变化频繁，而且依赖很多应用层数据，不适合在SQL里写CASE。但如果只是需要统计每个用户应该推送的文案类型数量，那就适合在SQL里做汇总，先用CASE加工出推送类型，再用GROUP BY统计。

从维护角度讲，SQL里的CASE分支一旦超过5个，最好加注释说明每个分支的业务含义，否则三个月后自己看都会发懵。我习惯在每个CASE的WHEN行上加一行注释，标明对应业务条件，能省很多维护成本。

结尾：一点个人经验

我用了好几年PostgreSQL，CASE WHEN是日常写SQL时最顺手又最容易出细节问题的功能。它看起来像if-else的SQL翻译，但只有用熟了才会理解它的设计逻辑：分支按顺序匹配、不带ELSE返回NULL、聚合上下文里配合条件计数和条件求和、排序里做业务优先级映射。这些都是普通文档里不会强调、但实际写报表时最能提效的细节。

我最开始频繁踩坑的场景是忘记ELSE导致结果集里出现NULL，以及在ORDER BY里写CASE时因为条件顺序处理不对导致排序结果不直观。后来养成了一个习惯：每次写完CASE，先数一下所有WHEN条件是否能覆盖业务里的全部取值，如果覆盖不了就写ELSE；再复查一下每个分支返回值的类型是否完全一致。这个小习惯大大减少了线上报错和返工率。

如果你想进阶，建议把CASE WHEN与表达式索引、窗口函数、CTE组合起来用。比如在CTE里先用CASE把用户打标，外层再基于标签做聚合统计，这种写法不仅可读性好，性能也远比不停嵌套子查询可靠。项目里遇到报表逻辑时，我也总会先想能不能用CASE WHEN解决，而不是直接拿到应用层循环。这个习惯让我的SQL简洁了非常多。