SQL CASE WHEN 进阶：条件求值、报表统计与性能优化全解析

CASE WHENSQL条件聚合

于 2026-10-01 05:12:53 修改

·本内容遵循CC 4.0 BY-SA版权协议

上周帮业务部门做一张用户分层报表，需求很简单：把近一年有下单的用户按累计消费金额分成四档，再统计每档的人数和客单价。我第一反应是写四个查询再拼到一起，写完同事看了一眼说：“一个 CASE WHEN 就解决了。”这句话让我愣了一下，随即意识到自己把简单问题复杂化了。

CASE WHEN 大概是每个写 SQL 的人第一天就会见到的关键字，语法看起来毫无门槛，翻来覆去就是“当什么条件成立就返回什么值”。但在我做了多年数据分析、也帮人排查过无数段 SQL 之后，可以负责任地说：能把 CASE WHEN 用得优雅、准确、还不踩坑的人，其实不算多。很多线上事故和报表口径对不上，追根究底都是 CASE WHEN 的条件顺序、NULL 处理或者类型转换出了问题。

这篇文章不打算讲教科书上那些干巴巴的语法说明，而是围绕我实际业务里用 CASE WHEN 最常见的场景，把语法本质、报表技巧、性能陷阱和跨数据库差异一次性讲透。不论你是刚接触 SQL 的新手，还是已经在生产环境摸爬滚打几年的老手，应该都能找到值得收藏的一段。

1. CASE WHEN 的语法本质：先搞懂它到底怎么求值

1.1 简单 CASE 和搜索 CASE，你更适合哪一种

CASE WHEN 在 SQL 标准里其实提供了两种写法。第一种叫简单 CASE，格式是 CASE 表达式 WHEN 值 THEN 结果，它做的事情是把一个表达式和若干离散值做等值匹配，最适合“把状态码翻译成人话”这种场景：

SQL

SELECT

user_id,

CASE status

WHEN 0 THEN '正常'

WHEN 1 THEN '锁定'

WHEN 2 THEN '已注销'

ELSE '未知'

END AS status_name

FROM users;

第二种叫搜索 CASE，格式是 CASE WHEN 条件 THEN 结果，条件是任意布尔表达式，可以写范围、模糊匹配、逻辑组合，几乎无所不能：

SQL

SELECT

order_id,

amount,

CASE

WHEN amount >= 10000 THEN '大单'

WHEN amount >= 5000 THEN '中单'

ELSE '小单'

END AS order_level

FROM orders;

两者的区别一句话就能说清：简单 CASE 只能做等值判断，搜索 CASE 什么判断都能做。实际业务里 90% 的场景我推荐用搜索 CASE，原因很简单——需求永远比你想象的复杂。今天可能还只是状态码等于 0、1、2，明天产品经理就会让你加一个“状态为 0 且创建时间在三个月前”的条件，简单 CASE 直接歇菜，搜索 CASE 却只需在条件里加个 AND。

1.2 从上到下的短路求值，和你想的不一样

这是新手最容易翻车的地方，也是 CASE WHEN 最核心的求值机制：CASE WHEN 严格按照书写顺序从上到下依次判断，只要命中第一个成立的 WHEN，就立刻返回对应的 THEN 结果，后面的所有 WHEN 不再执行。

看这个经典错误写法：

SQL

SELECT

score,

CASE

WHEN score >= 60 THEN '及格'

WHEN score >= 90 THEN '优秀'

ELSE '不及格'

END AS grade

FROM exam;

逻辑上看起来是先判及格再判优秀，但实际执行时，90 分也大于等于 60，所以直接命中第一个 WHEN，返回“及格”。“优秀”这个分支永远没有机会执行。这种 bug 在报表里极其隐蔽，因为结果不是报错，而是数据看起来“好像也能用”，直到有人发现成绩 95 分的学生被莫名其妙地标记成了及格。

解决办法有两个。一是调整顺序，把更严格、更大的条件放在前面：

SQL

CASE

WHEN score >= 90 THEN '优秀'

WHEN score >= 60 THEN '及格'

ELSE '不及格'

END

二是把边界写精确，避免区间重叠。这两种思路里我更推荐第一种，利用的就是短路机制：条件从大到小排列后，后面的 WHEN 天然承接了“前面没命中”的含义，代码更简洁，也不容易漏边界。

1.3 ELSE 缺省等于 NULL：统计结果里凭空出现的“未知组”

CASE WHEN 里 ELSE 是可选的，很多人图省事不写。但如果所有 WHEN 条件都不满足，CASE 表达式会返回 NULL，而不是空字符串或 0。NULL 在 GROUP BY 分组时会被单独分成一组，于是你的报表里就会莫名其妙地多出一个“未知”分组，里面装着所有边界数据。

经验之谈：不管业务上是否可能有其他值，我都建议把 ELSE 显式写出来。哪怕你确定不会走到 ELSE，也写上 ELSE NULL，阅读代码的人至少知道这里存在兜底分支，排查问题时能少走弯路。

我印象很深的一次：某天报表里多了一个“未分层”组，拉出来一看全是退款用户和测试用户，原因就是写 CASE WHEN 的时候图省事漏了 ELSE。那一刻真的想给自己一巴掌。

2. 报表里最常用的三招：分段、映射与多口径计算

2.1 数值分段：一个查询替代四个查询

回到开头那个用户分层需求。最朴素的方案是写四条 SQL，分别统计核心用户、高价值用户、普通用户、新用户的人数。四份数据肉眼看上去没问题，但一旦遇到夜间批量任务，每次统计的时间点存在细微差异，最终报表的四个数字可能对不上——因为它们查的是同一张表在不同时间点的快照。

正确做法是让一条 SQL 同时完成分层和统计：

SQL

SELECT

CASE

WHEN lifetime_value >= 100000 THEN '核心用户'

WHEN lifetime_value >= 50000 THEN '中高价值用户'

WHEN lifetime_value >= 10000 THEN '普通用户'

ELSE '新用户/低活跃'

END AS user_segment,

COUNT(*) AS user_cnt,

ROUND(AVG(lifetime_value), 2) AS avg_lifetime_value

FROM user_stats

WHERE stat_date = '2024-06-30'

GROUP BY user_segment

ORDER BY user_cnt DESC;

这个写法的核心价值不只是少写几条 SQL，而是保证所有统计口径在同一时刻、同一次扫描内完成。GROUP BY 一个表达式作为分组键是 SQL 的标准能力，CASE WHEN 的求值结果可以当作普通的别名列使用，这一点很多初学者没意识到。

2.2 字段值归一化：用 CASE WHEN 做数据清洗

热搜词里有“清洗---sql语句去重”，数据清洗确实是 CASE WHEN 的主场之一。举个最典型的场景：系统升级后，来源表里的状态字段既有数字也有字符串，还夹杂着大小写不一致和前后空格：

SQL

SELECT

order_id,

pay_flag,

CASE

WHEN TRIM(LOWER(pay_flag)) IN ('1', 'y', 'yes', 'paid') THEN '已支付'

WHEN TRIM(LOWER(pay_flag)) IN ('0', 'n', 'no', 'unpaid') THEN '未支付'

ELSE '异常状态'

END AS pay_status_standard

FROM legacy_orders;

用 TRIM 去掉空格，用 LOWER 统一大小写，再把所有“看起来表示已支付”的写法归成一个标准值。这个归一化结果列可以直接用于后续的分组统计，也能配合 ROW_NUMBER 做去重——先把脏值清洗成标准值，再按业务主键排序取一条，比在脏数据上直接去重要可靠得多。

2.3 同一字段的多口径结果并排输出

还有一种高频需求：同一张订单表，要同时统计总金额、已支付金额、退款金额。常规做法是三个子查询再 JOIN，其实 CASE WHEN 加条件聚合几行就能搞定：

SQL

SELECT

SUM(total_amount) AS all_amount,

SUM(CASE WHEN pay_status = 'paid' THEN total_amount ELSE 0 END) AS paid_amount,

SUM(CASE WHEN refund_status = 'refunded' THEN total_amount ELSE 0 END) AS refund_amount

FROM orders

WHERE order_date >= '2024-01-01';

这样做的意义在于一次全表扫描就把所有口径算完。如果拆成多个 SQL，大表上就是扫描 N 次，慢且不说，还存在口径漂移的风险。把多个统计口径放在同一个 SELECT 里，执行计划会合并成一次扫描，代价几乎不变，输出却整齐得多。

3. 行转列：CASE WHEN 最被低估的威力

3.1 一条 SQL 把行数据掰成多列

行转列（pivot）是报表开发里几乎绕不开的需求。比如有一张学生成绩表，每行是一个学生的一个科目成绩，要输出成“一行一个学生、每科一列”的宽表。用 CASE WHEN 配合聚合函数是最通用、最不需要额外权限的写法：

SQL

SELECT

student_id,

MAX(CASE WHEN subject = '语文' THEN score END) AS chinese,

MAX(CASE WHEN subject = '数学' THEN score END) AS math,

MAX(CASE WHEN subject = '英语' THEN score END) AS english

FROM score_detail

GROUP BY student_id;

这里有一个新手必问的问题：为什么要套 MAX()？因为 GROUP BY student_id 之后，每个学生对应多行科目记录，CASE WHEN 只是在每个原始行上挑选出属于该科目的分数，对不上的科目返回 NULL。一个学生有多行，多行里只有一个“语文”分数，其余都是 NULL，必须用聚合函数把非 NULL 的那一个值从一组行中“抽”出来。MAX 或 MIN 在这里只是一个取数工具，并不是真的要计算最大值。

3.2 SUM、COUNT、AVG 与 CASE WHEN 的搭配细节

条件聚合的写法里藏着一个极其经典的坑，我见过不止一个人在这里栽跟头。先看这个例子：

SQL

SELECT

region,

COUNT(CASE WHEN order_type = 'new' THEN 1 END) AS new_orders,

COUNT(CASE WHEN order_type = 'repeat' THEN 1 END) AS repeat_orders,

AVG(CASE WHEN order_type = 'new' THEN amount END) AS avg_new_amount

FROM orders

GROUP BY region;

注意 COUNT 里的 THEN 1 后面没有 ELSE。当条件不满足时，CASE WHEN 返回 NULL，COUNT 会自动忽略 NULL，所以统计的是“满足条件的行数”。这是我从第一天起就推荐的写法。

但如果你顺手写成了 COUNT(CASE WHEN order_type = 'new' THEN 1 ELSE 0 END)，那恭喜你，统计结果永远是全表行数——因为 0 也是非 NULL 值，COUNT 照样把它数进去。这个差异在报表上很难一眼看出问题，因为数值看起来“好像是那么回事”，只有当你手工核对明细时才会发现数量对不上。

提醒：AVG 里如果不对不满足条件的行做处理，比如 AVG(CASE WHEN order_type = 'new' THEN amount END)，那么不满足条件的行的 amount 会被视为 NULL，AVG 自动忽略，这通常正是我们想要的行为。但如果你想要的是“把不满足条件的行按 0 参与平均”，就必须写 ELSE 0。

3.3 列是写死的：动态列怎么处理

CASE WHEN 行转列的局限也很明显：每一列都是代码里写死的。如果科目或月份是动态变化的（比如用户自定义字段），就得考虑动态 SQL，或者用数据库自带的透视语法，比如 MySQL 的 GROUP_CONCAT 配合拼接语句、SQL Server 和 Oracle 的 PIVOT、PostgreSQL 的 crosstab 扩展。CASE WHEN 适合列集合稳定、且需要同时兼容多个数据库的场景；如果列完全动态，用数据库专用方案会更省力。这条经验是：先判断需求是“固定报表”还是“自助分析”，再决定要不要上动态列。

4. 空值与边界条件：CASE WHEN 最常见的四个坑

4.1 用 = NULL 永远判断不出来

SQL 里的 NULL 不是一个值，而是一种“未知”状态。任何与 NULL 的比较都不会返回 TRUE，而是返回 NULL。所以 CASE WHEN col = NULL THEN '空' ELSE '非空' END 永远会走 ELSE，因为 col = NULL 这个表达式的求值结果是 NULL，而 NULL 在 WHEN 中被视为不成立。

正确写法只有一种：用 IS NULL 或 IS NOT NULL。

SQL

CASE

WHEN col IS NULL THEN '空'

ELSE '非空'

END

这个坑在所有数据库里通用，也是热搜词“sql去除空值”背后最常见的问题来源。很多人想筛出空值，结果写出来的条件永远不生效。

4.2 COALESCE、IFNULL、NVL 与 CASE WHEN 的等价关系

处理 NULL 的函数各数据库都有，但都逃不出 CASE WHEN 的逻辑。等价关系可以参考下表：

写法	等价于 CASE WHEN
`COALESCE(a, b, 0)`	`CASE WHEN a IS NOT NULL THEN a WHEN b IS NOT NULL THEN b ELSE 0 END`
`IFNULL(a, 0)`（MySQL）	`CASE WHEN a IS NOT NULL THEN a ELSE 0 END`
`NVL(a, 0)`（Oracle）	`CASE WHEN a IS NOT NULL THEN a ELSE 0 END`
`NULLIF(a, b)`	`CASE WHEN a = b THEN NULL ELSE a END`

理解这个等价关系，你就能在“用函数简洁处理”和“用 CASE WHEN 灵活扩展”之间自由切换。比如只取第一个非 NULL 值，COALESCE 足够了；但如果逻辑复杂到“a 非空取 a，b 大于 100 取 b，否则取 0”，函数就无能为力，只能 CASE WHEN 上场。

4.3 THEN 分支返回不同类型引发的隐式转换

CASE WHEN 的所有 THEN 和 ELSE 返回的值会被数据库统一成一个数据类型。最典型的反面例子是：

SQL

CASE

WHEN type = 1 THEN amount

ELSE '无'

END

amount 是数值类型，'无' 是字符串，数据库会把整列结果隐式转换成字符串。于是 1234.56 变成了 '1234.56'，后续想 SUM、想比较大小，全部乱套。更隐蔽的是字符串排序问题：'10' 在字符串排序里排在 '9' 前面，你以为是数值排序，实际完全是另一套规则。

经验之谈：同一个 CASE WHEN 里的所有返回分支，务必保持同一种数据类型。如果业务上必须输出“数值或占位符”，用 0、-1 或显式 CAST 成统一类型，不要用文本。

4.4 区间边界：不要重叠，也不要漏掉端点

做分段统计时，最常见的错误是把两个条件都写成闭区间，导致端点值被重复计数，或者两个区间之间出现空隙。比如 0-18 和 18-30，18 到底算哪个区间，取决于写法。利用 CASE WHEN 的顺序求值特性，可以写出既不用考虑下界、又不会重叠的干净版本：

SQL

CASE

WHEN age < 18 THEN '未成年人'

WHEN age < 30 THEN '18-29岁'

WHEN age < 50 THEN '30-49岁'

ELSE '50岁以上'

END

因为条件从上到下依次判断，只要第一个不成立，就说明 age >= 18，自然落入第二个区间。这样每个区间只写上限，下界由前面的条件隐含保证，端点绝对不会重叠，也绝对不会漏掉。这也是我反复强调“范围和顺序一起设计”的原因。

4.5 空字符串和 NULL 是两回事

IS NULL 判断不了一个空字符串 ''。业务系统里经常有人用空字符串表示“没有填”，而数据库用 NULL 表示未知，两者并存时特别容易出问题。判断时要么 col = ''，要么用 LENGTH(TRIM(col)) = 0。写 CASE WHEN 之前，先搞清楚业务里“空”到底指什么——NULL 和 '' 千万别混着用。

5. 窗口函数时代：CASE WHEN 与 ROW_NUMBER、PARTITION BY 的组合技

5.1 分组去重：优先取“符合条件”的那条记录

窗口函数现在是 SQL 进阶的必修课，CASE WHEN 在窗口函数里配合使用尤其出效果。先看最经典的分组去重——每个用户最近的一条订单：

SQL

SELECT user_id, order_id, order_time, amount

FROM (

SELECT

ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC) AS rn

FROM orders

) t

WHERE rn = 1;

这是热搜词“sql窗口函数”里的标配写法。但很多场景会比这更复杂：比如我想取“每个用户最近一条已支付的订单”。如果直接按时间排序，可能取到的是未支付订单。这时可以用 CASE WHEN 在窗口函数的排序键里标记优先级：

SQL

SELECT user_id, order_id, order_time, amount

FROM (

SELECT

ROW_NUMBER() OVER (

PARTITION BY user_id

ORDER BY

CASE WHEN pay_status = 'paid' THEN 0 ELSE 1 END,

order_time DESC

) AS rn

FROM orders

) t

WHERE rn = 1;

这里 ORDER BY CASE WHEN ... THEN 0 ELSE 1 END 的意思是：已支付订单排在前面，未支付订单排在后面，再按时间倒序取第一条。一条 SQL 就完成了“既要过滤条件、又要去重取最近”的需求，这比“先去重再在代码里过滤”要高效得多，也比“先过滤已支付再去重”更准确。

5.2 组内比较：CASE WHEN 里直接嵌套窗口函数

窗口函数可以在 CASE WHEN 的条件里使用。比如统计销售人员是否超过本区域平均业绩：

SQL

SELECT

sales_name,

region,

amount,

AVG(amount) OVER (PARTITION BY region) AS region_avg,

CASE

WHEN amount >= AVG(amount) OVER (PARTITION BY region) THEN '超标'

ELSE '未达标'

END AS flag

FROM sales;

这个写法的价值在于：不用先开子查询算区域均值，也不用做自连接，一条 SELECT 直接完成“组内比较”。在当前行里，窗口函数已经计算出了整个分区的聚合值，CASE WHEN 只是把这个值和当前行的 value 做比较。数据量大时，这种写法通常比老式的“先 GROUP BY 再 JOIN”性能更好，因为执行计划可以直接基于窗口计算完成标记。

5.3 用 LAG 判断趋势：注意窗口返回 NULL 时 CASE WHEN 的表现

LAG 是取前一行的值，常用来判断环比涨跌：

SQL

SELECT

dt,

amount,

LAG(amount) OVER (ORDER BY dt) AS prev_amount,

CASE

WHEN amount > LAG(amount) OVER (ORDER BY dt) THEN '涨'

WHEN amount < LAG(amount) OVER (ORDER BY dt) THEN '跌'

ELSE '平'

END AS trend

FROM daily_sales;

第一行的 LAG 返回值是 NULL，所以两个比较条件都为 NULL，当条件为 NULL 时 CASE WHEN 会走 ELSE，这里会标记成‘平’。这个行为在某些报表里是符合直觉的，但在另一些场景里你希望第一行显示“无对比”。处理方式很简单：要么在 CASE WHEN 里显式判断 LAG(...) IS NULL，要么用 COALESCE 把 NULL 替换成一个能参与比较的基准值。这个细节如果不注意，报表的趋势列第一行就会出现你意想不到的结果。

6. 性能视角：CASE WHEN 写不好也会拖累整个 SQL

6.1 命中率高的条件放前面，对大数据量有意义

CASE WHEN 的短路求值特性决定了条件是有“执行成本”的。如果被判断的字段有 95% 的数据都满足第一个 WHEN，那么其余 95% 的行只做一次条件判断就结束了；反过来，如果第一个 WHEN 只覆盖 5% 的数据，剩下的 95% 行都得继续往下走。这个优化在几万行的小表上完全可以忽略，但在千万行级的大表上，条件判断的次数差异会直接影响 SQL 耗时。

我的经验是：把命中率最高的条件排在最前面，比如状态字段大部分是‘正常’时，先判断‘正常’，再判断各种异常分支；分段统计时，短的区间在前，长的区间在后。不过别为了排序把代码可读性牺牲掉。先用 EXPLAIN 看看瓶颈到底在哪里，再做条件重排，这个顺序不要反。

6.2 WHERE 里包 CASE WHEN 可能让索引失效

CASE WHEN 放在 SELECT 里做标记和口径，基本不影响性能，但放在 WHERE 子句里包裹字段，就需要警惕了。看这段：

SQL

-- 索引友好：直接用字段的布尔表达式

WHERE status = 'paid' OR status = 'finished'

-- 索引不友好：字段被 CASE WHEN 包了一层

WHERE CASE WHEN status IN ('paid', 'finished') THEN 1 ELSE 0 END = 1

第二种写法的问题是，数据库优化器很难把 CASE WHEN 转换回索引范围扫描，因为每一行都必须现场计算这个表达式才能判断是否成立。这涉及到可搜索参数（SARG）的概念：WHERE 里的条件最好能直接基于字段值做比较，而不是在字段上套一层函数或表达式。CASE WHEN 在 WHERE 里偶尔会出于复杂逻辑而不得不使用，但只要能用等值、范围、IN 直接表达，就别包 CASE WHEN。

6.3 嵌套超过三层就拆开：先标记再过滤

三层以上的嵌套 CASE WHEN，我几乎每次都建议重写。嵌套越深，缩进越长，逻辑越难验证，而且任何一层条件写错，排查成本都是指数级上升。

更稳的思路是把“复杂的判断逻辑”先用 CASE WHEN 生成一个标记列，外层再基于这个标记列过滤或统计：

SQL

SELECT *

FROM (

SELECT

CASE

WHEN amount >= 10000 AND pay_status = 'paid' THEN 'A'

WHEN amount >= 5000 AND pay_status = 'paid' THEN 'B'

WHEN amount >= 5000 THEN 'C'

ELSE 'D'

END AS grade

FROM orders

) t

WHERE grade IN ('A', 'B');

内层负责算标记，外层负责消费标记。这样每个 CASE WHEN 的逻辑都控制在一屏以内，出问题也只需要检查内层一个表达式。

6.4 用 CASE WHEN 硬编码还是 JOIN 维表

当 CASE WHEN 写了一大串来翻译状态码时，要停下来想一想：这个枚举值以后会不会增加？如果会，维表是更好的选择。比如状态翻译，JOIN 一张状态维表，新增状态只需要插数据，不用改 SQL。但如果只是一次性报表的统计规则（比如金额分档），硬编码 CASE WHEN 更轻量。

性能上在百万级表上两者差距通常不大，真正要小心的是 JOIN 维表可能因为维表 key 不唯一而放大数据量，导致行数变多、聚合结果出错。如果走维表，务必先确认维表 key 的唯一性。CASE WHEN 没有这个问题，因为它只是对当前行做纯判断，不会改变表的行数。

7. 跨数据库的差异：同一段 CASE WHEN 怎样写才能到处跑

7.1 标准 SQL 的胜利：主流数据库的兼容性非常好

先说结论：CASE WHEN 是 SQL 标准语法，MySQL、PostgreSQL、SQL Server、Oracle、SQLite 基本都实现了同样的语义，写法几乎没有差别。这也是我团队内部约定“条件分支一律用 CASE WHEN”的根本原因——可移植性好，换数据库不用重写。

各数据库还有一些私有的等价函数，但都不如 CASE WHEN 通用：

数据库	替代函数	局限
MySQL	`IF(expr, a, b)`	只能表达单条件二分支
Oracle	`DECODE(expr, 值1, 结果1, ..., 默认值)`	只支持等值匹配，不支持范围
SQL Server	`IIF(condition, a, b)`	只能表达单条件二分支

这些函数在自己数据库里写起来确实简洁，但一旦涉及跨数据库迁移或多库开发，维护成本立刻上来。我见过不少从 Oracle 迁到 MySQL 的项目，代码里一堆 DECODE 需要手工转换，而用 CASE WHEN 的地方几乎不用动。

7.2 几个容易踩的数据库方言细节

CASE WHEN 本身一致，但各数据库对 NULL、字符串空值、排序规则的差异会影响行为。

PostgreSQL 对布尔表达式的支持最好，CASE WHEN 条件里可以直接写布尔列，比如 WHEN is_active THEN '是' ELSE '否' END，比显式比较 is_active = true 更简洁。MySQL 在 ONLY_FULL_GROUP_BY 模式下，SELECT 的输出列如果不是聚合列就必须出现在 GROUP BY 里，写行转列时记得把 CASE WHEN 包进 MAX 或 SUM，别直接裸列。SQL Server 的字符串比较默认不区分大小写，状态码比较一般没问题，但如果大小写代表不同含义，需要显式处理排序规则或使用二进制排序。

Oracle 有个特别坑的细节：空字符串 '' 会被自动转换成 NULL。也就是说在 Oracle 里写 CASE WHEN col = '' 永远不成立，正确写法是判断 col IS NULL。从 MySQL 迁移到 Oracle 的团队，经常在这里踩一跤。

7.3 一个跨库通用模板：分段 + 多指标统计

综合上面的内容，给你一个我在多个数据库里都用过的通用模板，结构是从十几张报表里沉淀出来的：

SQL

SELECT

region,

COUNT(*) AS total_cnt,

COUNT(CASE WHEN amount >= 1000 THEN 1 END) AS high_cnt,

COUNT(CASE WHEN amount < 1000 THEN 1 END) AS low_cnt,

AVG(CASE WHEN amount >= 1000 THEN amount END) AS high_avg,

AVG(CASE WHEN amount < 1000 THEN amount END) AS low_avg

FROM sales

WHERE sale_date >= '2024-01-01'

GROUP BY region;

这段 SQL 在 MySQL、PostgreSQL、SQL Server、Oracle 里基本不用改，日期格式和数据类型需要注意的地方极少。这就是为什么我坚持让团队成员把 CASE WHEN 作为条件分支的唯一主力写法——它已经是 SQL 世界的普通话。

最后分享一个我个人写 CASE WHEN 的习惯：当逻辑分支超过三个时，先在草稿纸上把条件和区间边界列一遍，确认区间连续、端点不重叠，再动笔写 SQL。这个习惯帮我少踩了太多统计口径的雷。另一个经验是条件顺序先排命中率高的分支，再考虑逻辑从大到小排列，这样性能和可读性都能兼顾。CASE WHEN 看起来简单，但真正做到从容不迫，靠的还是对求值顺序和 NULL 语义的透彻理解。