企业官网建设流程全解析

做数据分析、后端开发或者数据库运维的人，写SQL的时间一长，一定会发现这样一个规律：业务需求里只要出现“分情况”“如果是”“否则”这类说法，十有八九要在SQL里用CASE WHEN语句去实现。在PostgreSQL里，CASE WHEN是处理条件分支最基础也最高频的表达式，无论是字段打标、数据清洗，还是行转列、条件聚合、自定义排序，都离不开它。这篇就把我这些年用PostgreSQL写CASE WHEN的实际经验，从基础语法到进阶用法，从性能陷阱到排查技巧，一次性整理出来，希望帮你少走一些弯路。

这篇内容适合刚接触SQL、还没系统整理过CASE WHEN写法的新手，也适合写了好几年SQL但对某些边界场景不够确定的同学。我不会按文档式的八股来写，而是按提数场景和实操过程一条条展开，该给代码给代码，该讲原理讲原理，该提醒的坑一个不漏。

1. CASE WHEN基础语法与执行逻辑

很多人在项目里用CASE WHEN属于“会用但说不清”，一旦遇到复杂嵌套、类型不匹配、条件顺序出错，就靠试错排查。所以先把基础语法和执行逻辑彻底讲透，后面所有场景都是在这两块地基上搭出来的。

1.1 两种基本写法：简单CASE与搜索CASE

PostgreSQL里的CASE表达式一共有两种写法，业务上都叫CASE WHEN，但语法结构和使用场景完全不同。

第一种叫简单CASE表达式，它是对某一个字段或表达式做等值判断。结构是这样：

CASE 字段 WHEN 值1 THEN 结果1 WHEN 值2 THEN 结果2 ... ELSE 默认结果 END

这种写法适合枚举字段的映射。比如支付渠道只有固定几种值，想转成中文名，用简单CASE最顺手：

SELECT order_id, CASE channel WHEN 'app' THEN 'APP' WHEN 'web' THEN '网页' WHEN 'miniapp' THEN '小程序' ELSE '其他' END AS channel_name FROM orders;

第二种叫搜索CASE表达式，WHEN后面跟一个完整的布尔条件：

CASE WHEN 条件1 THEN 结果1 WHEN 条件2 THEN 结果2 ... ELSE 默认结果 END

搜索CASE能覆盖简单CASE的所有场景，并且可以做区间判断、NULL判断、多条件组合，甚至子查询。实际项目里90%以上的场景用的是搜索CASE。

这里有一个很多人忽略的点：简单CASE做等值匹配时，它的比较语义等同于字段 = 值，所以如果字段本身是NULL，NULL = 值的结果是NULL而不是TRUE，这种情况下简单CASE不会匹配任何分支，直接落到ELSE。而搜索CASE里你可以显式写WHEN 字段 IS NULL THEN ...，这也是我为什么更推荐搜索CASE的原因。

1.2 搜索CASE的执行顺序：谁先匹配谁生效

搜索CASE是自上而下逐条判断的，一旦某个WHEN条件为真，就返回对应的THEN结果，后面的WHEN子句全部不再执行。这个特性决定了条件顺序本身就是业务逻辑的一部分，在区间划分场景里特别容易踩坑。

举个例子，给订单金额划分档位：

SELECT amount, CASE WHEN amount >= 1000 THEN '高额' WHEN amount >= 100 THEN '中额' WHEN amount >= 0 THEN '低额' ELSE '异常' END AS amount_level FROM orders;

如果把amount >= 0这行提前到最前面，那所有非负金额全都会落到“低额”，“高额”“中额”永远出不来。这种问题通常发生在业务加需求、别人帮你补条件的时候，所以写区间类CASE WHEN一定要记住：约束最严格的条件写在最前面，然后逐步放宽范围。也可以反过来显式写出上下界，比如WHEN amount BETWEEN 1000 AND 999999 THEN '高额'，这样顺序错了也不会互相覆盖。

关于短路行为，PostgreSQL文档没有像编程语言那样严格承诺CASE WHEN一定是短路的，但实际执行时命中分支后确实不会评估后续条件。我的建议是：依赖“命中即停止”是可以的，但不要把nextval、随机函数这类带副作用的表达式塞进THEN分支，SQL本质是声明式语言，优化器在某些场景下会调整执行策略，副作用函数的执行次数和顺序都不该依赖。

1.3 分支结果的数据类型

CASE WHEN所有分支返回的表达式，最终会被PostgreSQL推导成一个公共类型。整数和浮点数放一起没问题，PG会自动把integer提升成numeric；但数字和文本混在一起就会出问题。

举个典型的例子：

SELECT CASE WHEN flag = 1 THEN 100 ELSE 'unknown' END;

PG会尝试找integer和text的公共类型，很多情况下会把整数值转成text。单独查一下没问题，但如果你把这个结果当成数字去聚合、去比较、去做加减法，就会暴露类型不匹配的问题。更常见的坑发生在ELSE里的空字符串''和日期、数值分支混在一起，导致隐式转换失败或者结果集出来后计算报错。

写CASE WHEN时，最好让所有分支返回同一个类型，如果实在没法统一，就显式写CAST。比如：

CASE WHEN flag = 1 THEN CAST(100 AS text) ELSE 'unknown' END

这样至少结果可预期，不会因为PG的隐式转换策略改变而出现诡异行为。

2. 提数场景里的高频用法

基础语法过完，进入真正的提数实战。我平时给业务方做数据支持，CASE WHEN的使用频率极高，下面挑几个典型场景逐一说明。

2.1 字段打标：把连续值切成可读的层级

报表需求里最常见的操作，就是给观测值打标签。用户年龄、订单金额、消费频次、响应时间这类连续字段，通常要先切成几个业务区间，然后再做透视统计。打标逻辑用CASE WHEN实现是最直接的。

比如给用户按累积消费金额分层：

SELECT user_id, CASE WHEN total_amount >= 10000 THEN 'VIP' WHEN total_amount >= 5000 THEN '高价值' WHEN total_amount >= 1000 THEN '中等价值' ELSE '低价值' END AS user_level FROM ( SELECT user_id, SUM(amount) AS total_amount FROM orders WHERE status = 'paid' GROUP BY user_id ) t;

这个语句跑完，再外层包一层GROUP BY就能直接出各层人数和GMV占比。我实际踩过的坑是：打标规则往往由业务方提供，但业务方描述规则时用的是口语化的“消费超过一万、五千这些档”，“超过”边界到底是>还是>=必须提前确认。否则同一个边界值可能被同时算进两个区间，报表和口径对不上，回头排查半天才发现是个符号问题。

还有一个容易被忽略的细节：打标字段在后续查询里会被反复引用。如果写在一个嵌套子查询里，外层再基于标签过滤、聚合，整个SQL会膨胀得很厉害。我的建议是把打标规则沉淀成视图或者CTE，一方面逻辑清晰，另一方面业务口径调整时只改一处，不用全文搜索替换。

2.2 数据清洗与空值兜底

CASE WHEN在数据清洗里经常充当兜底角色。空值替换、默认值补齐、脏数据归一化，都可以用CASE WHEN写得很清楚。

例如把订单表里的支付方式做归一化，兼容历史数据里各种写法：

SELECT order_id, CASE WHEN pay_method IN ('wxpay', 'wechat', '微信支付') THEN 'wechat' WHEN pay_method IN ('alipay', '支付宝', 'ALIPAY') THEN 'alipay' WHEN pay_method IS NULL OR pay_method = '' THEN 'unknown' ELSE 'other' END AS pay_method_normalized FROM orders;

这个例子有三个细节值得展开。第一，IN列表可以帮助减少重复条件，不用每个取值都写一遍=；第二，空字符串和NULL的区别必须处理，很多时候业务上它们是同一个意思，但SQL里必须分开判断；第三，除了CASE WHEN，PostgreSQL还提供了COALESCE、NULLIF这几个函数，单字段默认值替换其实用COALESCE更紧凑，比如COALESCE(pay_method, 'unknown')`。

我的习惯是：单字段做NULL兜底，优先COALESCE；多条件分支、多个字段联合判断，用CASE WHEN。能用专门函数表达的语义，不需要非写成CASE，简洁和可读性要平衡。

还有一种清洗场景也经常用到CASE WHEN：把不符合格式的数据过滤或标记出来。比如手机号校验、邮箱格式校验，可以在SELECT列表里打一个脏数据标记，方便人工复核：

SELECT user_id, phone, CASE WHEN phone ~ '^1[3-9][0-9]{9}$' THEN 'valid' ELSE 'invalid' END AS phone_status FROM users;

PostgreSQL的~操作符可以做正则匹配，配合CASE WHEN就能在数据进入正式报表前先做一轮质量摸底。

2.3 自定义排序：让结果按人为定义的顺序排列

CASE WHEN不仅能打标，还能直接控制ORDER BY的排序规则。这个技巧我几乎每周都用。

默认的字典序、数值序往往不符合业务预期。比如订单状态有pending、paid、shipped、cancelled，报表里希望按“未支付→已支付→已发货→已取消”的顺序展示，直接ORDER BY状态字段是排不出来的，因为默认是按字母顺序排的。

这时把CASE WHEN放进ORDER BY：

SELECT order_id, status, created_at FROM orders ORDER BY CASE status WHEN 'pending' THEN 1 WHEN 'paid' THEN 2 WHEN 'shipped' THEN 3 WHEN 'cancelled' THEN 4 ELSE 99 END, created_at DESC;

这里用简单CASE的等值映射写法，比搜索CASE更紧凑。这个技巧在处理报表展示、看板排序时非常好用，数据在数据库层就排好了，应用层不需要再做二次排序。

多维度自定义排序也能组合使用，比如先按状态固定顺序，再按金额区间固定顺序：

ORDER BY CASE status WHEN 'pending' THEN 1 WHEN 'paid' THEN 2 ELSE 3 END, CASE WHEN amount >= 1000 THEN 1 WHEN amount >= 100 THEN 2 ELSE 3 END;

这里要注意一个问题：如果排序字段本身是索引列，包一层CASE之后索引大概率失效，表数据量大时排序可能变慢。我一般建议先跑EXPLAIN确认是否走到了合理的执行计划，业务又确实频繁按同一个CASE表达式排序，可以考虑建表达式索引，后面第4节会专门讲。

2.4 WHERE和HAVING里的条件分支

CASE WHEN也能出现在WHERE和HAVING子句里。有个业务场景很典型：在某些条件下按一个字段过滤，在另一些条件下按另一个字段过滤。

SELECT * FROM orders WHERE CASE WHEN order_type = 'normal' THEN channel <> 'offline' WHEN order_type = 'vip' THEN amount >= 500 ELSE TRUE END;

逻辑上这种写法很直观，但我必须说明两个问题。

第一，CASE WHEN返回的结果类型要和右侧比较运算的类型匹配，分支里如果混入了类型不一致的列，会直接报错。第二，字段被包在CASE表达式里，普通索引基本派不上用场，数据量大的表会很吃亏。同样的逻辑，更推荐改写成纯布尔组合：

WHERE (order_type = 'normal' AND channel <> 'offline') OR (order_type = 'vip' AND amount >= 500);

这样既不影响语义，优化器也更可能利用到order_type、channel、amount上的单列索引。WHERE里能写布尔组合，就不要用CASE WHEN包一层，这是我的一个原则。

HAVING里的CASE WHEN用法套路和WHERE类似，通常用于“按分组后的结果再走一层条件分支”的场景。比如只保留满足特定组合口径的分组，写法就是把CASE表达式放在HAVING右边：

HAVING SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) > 10000 AND COUNT(CASE WHEN status = 'cancelled' THEN 1 END) < 10;

这里已经用到条件聚合的写法了，第3节我会重点展开。

3. 进阶场景：聚合、行转列与更新操作

基础用法跑顺之后，CASE WHEN更大的价值体现在和聚合函数、窗口函数配合的复杂查询里。这一节讲的都是实际项目中出场率极高的操作。

3.1 行转列：用CASE WHEN + MAX实现透视表

行转列是我做数据需求时遇到特别多的需求，也是CASE WHEN最经典的应用之一。

假设有一张销售明细表，包含月份和销售额，想把它转成“每个月份一列”的宽表：

SELECT product_id, MAX(CASE WHEN month = 1 THEN sales_amount END) AS m01, MAX(CASE WHEN month = 2 THEN sales_amount END) AS m02, MAX(CASE WHEN month = 3 THEN sales_amount END) AS m03 FROM monthly_sales GROUP BY product_id;

这里必须理解一个关键点：为什么外层一定要套聚合函数？因为GROUP BY之后，每个分组对应多行数据，而SELECT输出的每一列必须是聚合后的单值。CASE WHEN本身的职责是“挑出符合条件的那个值”，如果某个月份不满足条件，它返回NULL；MAX会忽略NULL，所以只要该分组里有满足条件的行，就能取到对应数值。

换句话说，CASE在这里负责“挑”，MAX负责“合并”。这两个动作缺一不可。如果某个分组里一个月有多条记录，MAX会取最大那条；如果希望取的是合计值，就用SUM替代MAX。用MIN替代MAX也可以，行为一致。

这个透视写法在报表工具里非常实用，比在应用层循环查表高效太多。字段少的时候直接写字段名，字段多的时候建议用程序生成拼接SQL，避免手写几十个重复的CASE分支。

3.2 条件聚合：SUM(CASE WHEN ...)统计不同口径

这是CASE WHEN最高频的进阶用法。统计订单表中不同状态下的金额和单量：

SELECT date, COUNT(*) AS total_cnt, SUM(amount) AS total_amount, COUNT(CASE WHEN status = 'paid' THEN order_id END) AS paid_cnt, SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) AS paid_amount, SUM(CASE WHEN status = 'cancelled' THEN amount ELSE 0 END) AS cancelled_amount FROM orders GROUP BY date;

为什么这里用SUM(CASE WHEN ...)而不是直接COUNT(CASE WHEN ...)？这取决于你要统计的指标是什么。COUNT统计的是“非NULL的条数”，如果THEN分支返回order_id，那只有满足status='paid'的行才返回非NULL，所以COUNT(CASE WHEN ...)其实就是在统计符合条件行数。SUM则更适合对金额、数量等数值字段做条件求和。

如果某个字段统计值本身可能为NULL，而你又需要“满足条件的行都计入条数”，写成SUM(CASE WHEN ... THEN 1 ELSE 0 END)最稳妥，因为NULL不会被SUM计算进去，但0会。总之，先想清楚落在那个指标上的语义是“条数”还是“数值累加”，再决定用COUNT还是SUM。

这里分享一个我的个人习惯：统计“满足某条件的记录条数”时，我更喜欢用PostgreSQL特有的聚合过滤语法COUNT(*) FILTER (WHERE 条件)，逻辑更直白：

COUNT(*) FILTER (WHERE status = 'paid') AS paid_cnt,

FILTER在条件较长时可读性更好，也和CASE WHEN在功能上等价。但如果你写的SQL需要在不同数据库之间迁移，CASE WHEN更通用，FILTER语法不是所有数据库都支持。项目里如果已经固定PostgreSQL技术栈，两种写法可以混用，看团队习惯统一。

3.3 窗口函数中使用CASE WHEN：算占比、做环比

窗口函数和CASE WHEN的结合也很有价值。比如要算每个用户不同状态订单的金额占比，可以先在窗口内标记出指定状态的数据，再参与窗口运算。

SELECT user_id, status, amount, SUM(amount) OVER (PARTITION BY user_id) AS user_total, SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) OVER (PARTITION BY user_id) AS user_paid_total FROM orders;

这个SQL实现了“按用户分组，只看已支付金额”的窗口汇总。注意CASE WHEN写在聚合函数参数里和写在OVER()外面的区别：写在参数里，是先对当前行做条件判断，再参与窗口聚合；写在OVER()外面，通常是在窗口结果上做判断。两种语义完全不同，写之前要看清楚自己到底要的是“每行带上一个窗口汇总值”，还是“每行根据窗口结果做分类”。

补充一个常被忽视的点：窗口聚合函数里的FILTER语法也是支持的。上面例子可以改写成：

SUM(amount) FILTER (WHERE status = 'paid') OVER (PARTITION BY user_id) AS user_paid_total

如果SELECT列表里还包含GROUP BY，FILTER和CASE WHEN的写法差异会更明显，因为窗口函数不受GROUP BY影响，两种方式结果一致。

3.4 在UPDATE里批量更新：同一语句完成多条件修改

CASE WHEN不只出现在SELECT语句里，也能用在UPDATE的SET子句中，解决“根据条件批量更新”的问题。

传统做法是一条UPDATE只改一类数据，多条UPDATE串行执行会有中间态不一致的风险。CASE WHEN可以在一条语句里完成多种条件的更新：

UPDATE orders SET status = CASE WHEN paid_at IS NOT NULL AND shipped_at IS NULL THEN 'to_ship' WHEN shipped_at IS NOT NULL THEN 'shipped' ELSE status END WHERE created_at >= date '2024-01-01';

这个写法的优势是原子性更强，一条语句完成全部状态流转，执行计划也只需要规划一次。但这里有个必须强调的细节：SET子句里的CASE WHEN不能省略ELSE。如果省略ELSE，落在所有分支之外的行会被更新成NULL，一旦WHERE范围没控制好，可能直接造成大范围数据置空。这是数据事故级别的坑，我在测试环境就犯过一次，幸好数据可以回滚，但教训很深。

另外，UPDATE里的CASE WHEN同样要注意类型统一，SET的列类型是预先确定的，分支返回的表达式都要能隐式转换成该列类型，否则直接报错。

4. 性能考量与常见易错点

CASE WHEN用的多了以后，踩坑频率会明显下降，但有些性能和逻辑问题仍然值得系统梳理。这一节我把最常见的问题集中讲透。

4.1 索引失效与表达式索引

先说一个核心结论：CASE WHEN本身不是性能毒药，要看它写在哪里。

写在SELECT输出列，对索引使用没有直接影响，只是每行记录多一次表达式计算；写在WHERE或ON条件里，如果把一个带索引的列包进CASE分支，优化器很难把它转换成对索引范围扫描的约束，普通索引大概率用不上；写在ORDER BY里，如果排序字段本身是索引列，包一层CASE之后索引也会失效。

如果业务经常需要按某个固定CASE表达式排序或者过滤，PostgreSQL可以建表达式索引：

CREATE INDEX idx_orders_status_order ON orders (CASE status WHEN 'pending' THEN 1 WHEN 'paid' THEN 2 END);

建立之后，查询里只要ORDER BY或WHERE的表达式和索引表达式完全一致，就可能走索引扫描。注意这里的“完全一致”非常严格，多一个空格、少一个CAST都可能匹配不上。所以表达式索引更适合“固定排序规则”的场景，临时变化的需求建索引反而不划算。

4.2 条件顺序对计算开销的影响

前面讲过CASE WHEN的自上而下命中逻辑。另一个不那么直观的影响是：条件顺序同样影响每行记录的平均计算开销。PostgreSQL的规划器对表达式本身的成本估算能力有限，当WHEN分支里包含函数调用、正则匹配、类型转换时，把最“便宜”、命中率最高的条件放前面，通常能减少每行平均计算量。

比如一个查询要对亿级表做数据质量筛查，条件顺序从简单到复杂：

CASE WHEN status IS NULL THEN 'empty' WHEN status ~ '^[0-9]+$' THEN 'number' ELSE 'text' END

IS NULL判断很便宜，放在最前面可以快速过滤掉大量空值行；正则匹配成本高，放到后面让空值行直接跳过。这种顺序优化在OLAP类大查询里有时能肉眼可见地缩短执行时间，值得养成习惯。

4.3 易错点一：ELSE省略引发的默认NULL

CASE WHEN的ELSE是可以省略的，省略后，不满足任何WHEN分支的行会返回NULL。很多时候这个行为是业务需要的，但更多时候是忘了写，结果报表里凭空多出一批空值。

我的建议很明确：凡是输出到报表、下游模型的CASE WHEN，都显式写上ELSE，哪怕业务上知道不会有其他情况，留一个兜底值也能让数据更干净。这个习惯帮我少排查了很多“奇怪的空值”问题。

4.4 易错点二：NULL不能用“=”比较

这个错误在CASE WHEN里同样高发。很多人写CASE WHEN col = NULL THEN 'a' ELSE 'b' END，以为能判断空值，结果所有行都走了ELSE。原因在于SQL的三值逻辑里，NULL = NULL的结果不是TRUE也不是FALSE，而是NULL，不满足WHEN条件的TRUE语义，所以只有col IS NULL是判断空值的正确写法。

如果列可能为NULL，在CASE判断时要么用IS NULL/IS NOT NULL，要么先用COALESCE把NULL替换成默认值再继续判断。写SQL的人最容易在这上面翻车，因为它和编程语言里的空值判断习惯完全相反。

4.5 易错点三：AND/OR优先级

CASE WHEN的WHEN子句里可以写多个条件并用AND/OR组合。这里有个隐藏的坑：AND的优先级高于OR，如果没有打括号，“要么满足A且B，要么满足C”这种口语化描述，写出来逻辑可能完全相反。

比如WHEN type = 1 AND status = 'a' OR status = 'b'，实际等价于(type = 1 AND status = 'a') OR (status = 'b')。一旦条件变多，信号就乱了。我的建议是：多条件组合时，每个意图组都用括号显式包起来，没有歧义。

4.6 易错点四：重复条件与冗余计算

还有一种不太容易发现的性能问题：多个WHEN分支里出现重复的子表达式。比如：

CASE WHEN category = 'A' AND amount > 100 THEN 'type1' WHEN category = 'A' AND amount > 50 THEN 'type2' END

第一个分支没命中时，第二个分支又要把category、amount的条件判断重算一遍。虽然PG有公共表达式提取能力，但在复杂表达式场景下不一定能完全合并。最好手工把公共条件提取出来，适当合并分支，或者先基于公共条件拆分SQL再往下走，可读性也会更好。

4.7 常见问题速查表

把前面讲的常见问题和解决思路整理成一张表，方便排查时对号入座。

5. 一个综合实战案例：从需求到SQL落地

前面所有知识点都是散的，这一节用一个贴近日常工作的综合案例串起来。这个案例我做过模拟，也在类似业务场景里验证过，可以直接作为参考模板。

5.1 需求背景

假设现在有一张订单表，字段有订单号、用户ID、订单金额、订单状态、支付渠道、创建时间。运营要看一张月度经营分析报表，要求包括：

• 订单总量、总GMV
• 不同支付渠道的订单量和GMV
• 新老用户的订单量占比
• 各金额区间的订单量分布
• 最后按“金额区间+渠道”做交叉明细列表，并按业务自定义顺序排序

这些需求单靠一个CASE WHEN不够，但每个环节几乎都会用到。

5.2 分步骤实现

第一步，给订单打上金额区间和用户类型标签：

SELECT order_id, user_id, amount, channel, status, CASE WHEN amount >= 3000 THEN '高额' WHEN amount >= 1000 THEN '中额' ELSE '小额' END AS amount_bucket, CASE WHEN user_id IN ( SELECT DISTINCT user_id FROM orders WHERE created_at < date '2024-01-01' ) THEN '老用户' ELSE '新用户' END AS user_type FROM orders;

第二步，统计各渠道及金额区间的交叉数据：

SELECT channel, amount_bucket, COUNT(*) AS order_cnt, SUM(amount) AS total_amount, COUNT(CASE WHEN user_type = '老用户' THEN 1 END) AS old_user_cnt FROM ( -- 第一步的子查询结果 ) t GROUP BY channel, amount_bucket;

第三步，在展示SQL里添加自定义排序：

ORDER BY CASE channel WHEN 'app' THEN 1 WHEN 'web' THEN 2 WHEN 'miniapp' THEN 3 ELSE 99 END, CASE amount_bucket WHEN '高额' THEN 1 WHEN '中额' THEN 2 ELSE 3 END;

三步走完，一张经营分析的明细和汇总都可以在一个SQL里出完，不需要在应用层拼数据。

5.3 生产落地的几个习惯

把这套SQL放到生产环境跑之前，我一般会做三件事：

第一，提取一小批样本数据跑一遍，核对金额区间的边界值、渠道名称的归一化结果、新老用户口径是否符合业务定义。第二，执行EXPLAIN ANALYZE看有没有异常的全表扫描，如果金额区间字段是常用的过滤键，考虑加索引或者调整SQL写法。第三，把交叉汇总结果和明细数据做一次合计校验，比如各渠道订单量之和是否等于总订单量。

这套习惯帮我避免了很多“SQL跑起来没问题，报表结果却对不上”的尴尬情况。生产环境里除了调通SQL，数据口径的准确性永远是最重要的。

最后再分享一点我的体会

写到这里，CASE WHEN在PostgreSQL里从基础语法到综合实战已经讲完了。最后说点个人想法：很多人觉得CASE WHEN太基础，不需要专门总结，但在真实负责数据查询和报表工作的这些年里，我见过最多的SQL事故恰恰出现在这些“简单”语法上——ELSE漏写、NULL判断错误、区间条件顺序颠倒，每一个都导致过数据返工。CASE WHEN能玩出的花样并不少，关键是要带着“它出现在哪个子句，会影响什么”的意识去使用。下次写聚合报表前，不妨先把口径里所有“如果”“否则”用中文列清楚，再翻译成CASE WHEN，基本一次就能写对。