企业官网建设流程全解析

刚把PostgreSQL装好、连上数据库的那批人，十有八九会先翻文档找CASE WHEN。原因很简单：只要SQL里沾上一点业务逻辑——分类、打标签、区间统计、字段加工——这个语法就躲不掉。PostgreSQL的case when语句和其他数据库长得几乎一样，可真扔到生产环境里，NULL的脾气、类型的强制转换、条件聚合的性能差异，全是隐形的坑。这篇内容不打算讲教科书式的文法，而是从实际写过的报表SQL、数据订正脚本里，挑出真正值得注意的用法和踩过的坑。对刚把数据库版本捂热的新手，或者从MySQL、SQL Server迁过来的老手，都有参考价值。

1. 简单CASE和搜索CASE：先搞清楚你写的是哪一种

很多人在别的数据库里写了一两年CASE WHEN，换到PostgreSQL后写的第一条复杂SQL基本都是复制旧项目的。结果要么行为不对，要么直接报错。所以第一步，先把两种形态分清楚。

1.1 等值判断用简单CASE，范围判断用搜索CASE

PostgreSQL支持SQL标准里的两种CASE写法。简单CASE的长相是：

SELECT CASE order_status WHEN 1 THEN '待付款' WHEN 2 THEN '已付款' WHEN 3 THEN '已发货' ELSE '未知状态' END AS status_name FROM orders;

搜索CASE的长相是：

SELECT CASE WHEN order_status = 1 THEN '待付款' WHEN order_status BETWEEN 2 AND 3 THEN '已履约' WHEN order_status IN (0, -1) THEN '关闭' ELSE '未知状态' END AS status_name FROM orders;

两者差异说大不大说小不小。简单CASE只做等值比较，CASE后面的列会和每个WHEN后面的值逐个比较；搜索CASE则可以写任意布尔表达式。这意味着，一旦判断条件里出现大于、小于、LIKE、IN、BETWEEN、IS NULL，就老老实实用搜索CASE。我见过同事把简单CASE写成了CASE order_status WHEN > 2 THEN 'big' END，在PostgreSQL里直接语法报错，因为简单CASE的WHEN后面只能跟一个值表达式。另一个容易忽略的细节是，简单CASE里的值比较用的是等号语义，如果列本身含NULL，永远匹配不上任何WHEN，会直接落到ELSE。

下面这张表可以帮你快速决定用哪种：

一个小经验：新建的查询里，判断条件超过两条，我一般默认写搜索CASE，不为别的，就为以后加条件时不用重写整个结构。简单CASE只适合"一个字段多个固定取值"的映射，比如状态枚举，写起来确实更短。

1.2 ELSE不写会怎样：NULL比0更隐蔽

CASE WHEN的ELSE是可选的。不写ELSE，任何一个WHEN都没命中时，表达式返回NULL。这在SELECT输出里看起来只是一个空单元格，但一旦套上SUM、AVG、COUNT这类聚合函数，后果就不一样了。NULL参与聚合时会被忽略，而如果整个分组都没有命中条件，SUM结果是NULL，COUNT结果是0——两个不同的结果同时出现，你在报表上看到"没数据"和"汇总为空"往往要查半天。

我自己遇到过一次：统计某渠道每周转化率，SQL里写的是SUM(CASE WHEN source = 'wechat' AND converted THEN 1 ELSE 0 END) / COUNT(*)，这里给ELSE写了0，没问题。但另一个同事写的是SUM(CASE WHEN source = 'wechat' THEN amount END) AS wechat_amount，某周恰好没有任何wechat来源的订单，这个字段返回NULL，下游报表团队拿到NULL后直接渲染成空缺，业务方以为数据漏跑了。排查到最后，发现SQL本身没问题，就是ELSE少写了。

所以我现在的习惯是：所有CASE WHEN必须带ELSE，哪怕ELSE后面的值就是NULL，也要显式写出来。显式ELSE NULL和省略ELSE语义相同，但代码审查时能一眼看出设计者考虑过兜底情况。顺手推荐在写聚合型CASE WHEN时，直接给默认0，避免NULL污染汇总结果。比如SUM(CASE WHEN is_refund THEN amount ELSE 0 END)，分子永远是数值型聚合结果，不会因为整组没有命中条件就变NULL，后面也不需要再套COALESCE兜底。

2. NULL值处理：CASE WHEN最容易翻车的分水岭

PostgreSQL对NULL的态度相当严谨，这也导致从别的数据库过来的同事容易在CASE WHEN里翻车。这一章值得细看，因为涉及NULL的坑往往在测试小数据集上根本暴露不出来，等数据量一旦上来，结果就是错的。

2.1 别用=判断NULL，IS NULL才是对的路

搜索CASE里最常见的错误是：

CASE WHEN nickname = NULL THEN '未设置' ELSE nickname END

这条语句永远不会走到THEN分支。因为NULL不是具体值，它表示"未知"，任何和NULL做等值比较的结果都是NULL，也就是不成立。这在WHERE里已经是常识，可一旦挪进CASE WHEN，很多人就忘了。判断NULL必须写WHEN nickname IS NULL。

简单CASE里的NULL判断更隐蔽。假设你想判断某列是否为NULL，写：

CASE nickname WHEN NULL THEN '未设置' ELSE nickname END

这句也是错的。简单CASE展开后等价于nickname = NULL，永远为假。哪怕你确实要把"列内容等于某值"作为条件，只要该列可能出现NULL，就要考虑先处理NULL。这也是为什么我每次做数据质量检查，都会专门扫一遍代码里是否存在WHEN ... = NULL这种写法——出现一个，基本就能断定这段逻辑从上线起就没真正工作过。

2.2 把NULL映射成业务默认值的几种姿势

处理NULL映射，我见过三种常见写法：

-- 写法A：CASE WHEN 里直接判断 CASE WHEN nickname IS NULL THEN '未设置' ELSE nickname END -- 写法B：外层套 COALESCE COALESCE(CASE WHEN status_code > 5 THEN '异常' END, '未知') -- 写法C：COALESCE本身解决简单映射 COALESCE(nickname, '未设置')

使用场景各有不同。写法A适合"只有在NULL时才给默认值，其他值要原样保留"；写法B适合"CASE运算结果可能是NULL，必须再兜一层"；写法C是纯字段缺省值替换，根本不需要CASE WHEN。我在用户画像表里常年用这组合：

SELECT COALESCE(province, '未知省份') AS province, COALESCE(NULLIF(gender, ''), '保密') AS gender FROM users;

NULLIF(gender, '')把空字符串转成NULL，再由COALESCE转成'保密'，一套组合拳把"空字符串"和"NULL"两种脏数据统一成业务默认值。CASE WHEN同样能干这事，但NULLIF加COALESCE的可读性更高。

需要记住的是：PostgreSQL里空字符串''和NULL是两个完全不同的东西。CASE WHEN field IS NULL不会匹配到''，反过来field = ''也不会匹配到NULL。做数据清洗时，先想清楚你面对的是哪种"空"，否则清洗完依然是脏数据。

3. 性能与索引：CASE WHEN其实没有你想的那么"免费"

很多人觉得CASE WHEN就是个分支语句，随便写。但它终究是个表达式，出现在不同SQL位置时的执行代价天差地别。这一章专门讲性能，适合那些已经写过一阵子CASE WHEN、开始关心查询效率的人。

3.1 PostgreSQL对CASE表达式的求值机制

PostgreSQL执行CASE WHEN时，会逐个评估WHEN后面的条件，一旦命中就返回对应THEN值，不再继续往后的WHEN分支。这个行为在绝大多数情况下是短路式的。注意，我说的是"绝大多数情况下"。SQL标准里CASE的短路行为并没有被严格定义为通用保证，PostgreSQL文档也没有承诺优化器不会对表达式做重排。所以有一条铁律：不要往CASE WHEN的THEN或WHEN里写有副作用的函数，更不要指望CASE能帮你挡住除零错误、类型错误。你想防除零，应该先把数据过滤干净，或者用NULLIF：

-- 不建议依赖CASE短路 CASE WHEN amount <> 0 THEN total / amount ELSE 0 END -- 建议写成 COALESCE(total / NULLIF(amount, 0), 0)

NULLIF先把非法值处理掉，除法只会在合法值上执行，COALESCE再兜一个默认结果。四个函数嵌套读起来确实啰嗦，但执行语义比CASE WHEN直白得多——优化器没有任何理由改变这个执行结果。

另一个求值细节：简单CASE只会把CASE后面的表达式计算一次，然后和每个WHEN值比较；搜索CASE则每个WHEN条件都要单独计算。所以如果一个复杂的子表达式在多个分支里重复出现，先在一个子查询里把它算好，再在外层套CASE WHEN，是实打实能省CPU的。

3.2 什么时候CASE WHEN会拖慢查询

最典型的是WHERE条件里用CASE WHEN包列。下面这种写法是我在别人代码里见过很多次的：

WHERE CASE WHEN status = 'active' THEN created_at ELSE updated_at END > '2024-01-01'

这段SQL在功能上没错，但PostgreSQL无法直接对created_at或updated_at使用普通索引，只能全表扫描，一行行算完CASE再比较。如果表有上百万行，查询会明显变慢。改写思路是把条件展开成普通布尔逻辑：

WHERE (status = 'active' AND created_at > '2024-01-01') OR (status <> 'active' AND updated_at > '2024-01-01')

这样分别对两列走索引的机会就出来了。别抬杠说OR也可能导致性能问题，实际情况里大多数时候比包一层CASE好，而且PostgreSQL可以用BitmapOr把两个索引结果合并，优化器对普通条件的处理手段远比表达式丰富。

SELECT列表里的CASE WHEN通常没有这个索引问题，但如果在GROUP BY、ORDER BY里用CASE WHEN，要注意它让分组或排序无法利用索引顺序。排序字段如果是CASE表达式，数据库只能显式排序，数据量大时临时文件会撑爆内存，这也是常见的慢查询来源。

3.3 条件聚合：CASE WHEN和FILTER怎么选

做报表时经常要在一行里统计多个条件值：

SELECT date, COUNT(*) AS total_cnt, SUM(CASE WHEN is_churn THEN 1 ELSE 0 END) AS churn_cnt, SUM(CASE WHEN is_new_user THEN 1 ELSE 0 END) AS new_cnt FROM daily_stats GROUP BY date;

这是CASE WHEN条件聚合的经典写法。PostgreSQL 9.4以后还提供了FILTER子句：

SELECT date, COUNT(*) AS total_cnt, COUNT(*) FILTER (WHERE is_churn) AS churn_cnt, COUNT(*) FILTER (WHERE is_new_user) AS new_cnt FROM daily_stats GROUP BY date;

两种写法跑出来的执行计划在绝大多数版本里差别不大，FILTER可读性更好，而且PostgreSQL对FILTER的优化在持续增强。但如果你要在别的数据库上复用同一份SQL，CASE WHEN的可移植性明显更好——MySQL直到8.0还没有FILTER，SQL Server也没有。

我的习惯是：如果是PostgreSQL独占的报表库，优先FILTER；如果需要兼容多套数据库的数据仓库，用CASE WHEN保险。至于COUNT(DISTINCT CASE WHEN ... END)这种组合，在PG里能跑，但数据量大时distinct本身才是性能瓶颈，和CASE WHEN关系不大，得从数据模型层面解决。

4. 实战场景：行转列、区间分组与数据标准化

讲完原理，给三个我实际用过的场景，基本覆盖CASE WHEN在业务里的高频用途。每个场景我都会说清楚为什么这么写，以及有哪些替代方案。

4.1 行转列：聚合函数加CASE WHEN的经典组合

有个订单标签表，结构大概是user_id、tag_name，一行一个标签，一个用户有多行。想输出每个用户是否有VIP、是否有退款记录、是否高净值用户这三个布尔列，标准做法就是按user_id分组，对每个标签写一个CASE WHEN：

SELECT user_id, MAX(CASE WHEN tag_name = 'VIP' THEN 1 ELSE 0 END) AS is_vip, MAX(CASE WHEN tag_name = 'refund' THEN 1 ELSE 0 END) AS has_refund, MAX(CASE WHEN tag_name = 'high_value' THEN 1 ELSE 0 END) AS is_high_value FROM user_tags GROUP BY user_id;

为什么用MAX而不是SUM？因为一个用户可能存在重复标签，SUM会把同一标签的重复记录累加成2、3，MAX则保证结果只是0或1。如果只想标记"存在与否"，MAX是最稳的。想输出标签文本本身，把THEN 1改成THEN tag_name，MAX会取出非NULL的那条文本。

行转列时一定要记得GROUP BY里只放user_id，所有CASE WHEN都放在聚合函数里。我见过初学者把tag_name直接写进GROUP BY，结果行转列变成了行数翻倍，完全反了。这种错误在执行计划里很难一眼看出来，但结果一对比就露馅。

4.2 区间分组：订单金额分段统计

订单表orders里有amount字段，现在要统计0到100元、100到500元、500到2000元、2000元以上四个档位的订单数和销售额。直接用GROUP BY amount做不到，得先用CASE WHEN把金额映射到档位：

SELECT CASE WHEN amount < 100 THEN '0-100' WHEN amount < 500 THEN '100-500' WHEN amount < 2000 THEN '500-2000' ELSE '2000+' END AS amount_band, COUNT(*) AS order_cnt, SUM(amount) AS total_amount FROM orders GROUP BY amount_band ORDER BY amount_band;

注意区间边界：这里WHEN amount < 100先执行，之后原amount已经不可能小于100，所以第二个WHEN实际等价于amount BETWEEN 100 AND 499。条件顺序就是靠CASE WHEN天然帮你按序过滤。写区间CASE WHEN时，建议从最小值往最大值写，或者反过来从大到小，保持一个固定方向，逻辑不容易漏边界。

如果你希望报表里档位顺序不是按字符串排序（上面结果里'100-500'会排在'0-100'前面），可以把THEN里的字符串换成一个整数等级：

CASE WHEN amount < 100 THEN 1 WHEN amount < 500 THEN 2 WHEN amount < 2000 THEN 3 ELSE 4 END AS band_rank

排序用band_rank，展示时再映射一次。这是报表开发里很实用的技巧：当业务希望的排序规则和值本身的自然顺序不一致时，用CASE WHEN生成一个排序列，简单粗暴但有效。

4.3 数据标准化与异常数据清洗

从外部接口导入的数据经常出现同一含义的多种写法，比如省份字段有'北京市'、'北京'、'北京市 '、'beijing'。清洗时CASE WHEN配合LIKE和字符串函数：

SELECT CASE WHEN province LIKE '%北京%' THEN '北京市' WHEN province LIKE '%上海%' THEN '上海市' WHEN province ILIKE '%guangdong%' OR province LIKE '%广东%' THEN '广东省' ELSE '其他' END AS province_std FROM raw_users;

ILIKE是不区分大小写的LIKE，对英文脏数据非常管用。清洗逻辑写在SQL里比用程序代码逐行处理快，因为它直接在数据库端完成，不产生网络往返。不过要注意LIKE的模式匹配在数据量很大时无法利用普通索引，清洗过程一般是一次性任务，问题不大；如果是高频查询，还是应该建一张标准映射表JOIN更合适。

GROUP BY和CASE WHEN清洗配合时，有一个经典问题：GROUP BY后面写整段CASE表达式太长，写别名又依赖数据库对GROUP BY别名的支持。PostgreSQL其实允许GROUP BY后面跟别名，但遇到别名和真实列名重名时会按真实列处理，容易埋雷。我更推荐把清洗表达式包一层子查询，在外面再分组，结构清晰得多。

5. 嵌套CASE WHEN与可读性：写的时候爽，维护的时候哭

CASE WHEN能嵌套，但嵌套多了就不是给人看的代码了。我接手过一个老报表，里面有一段六层嵌套的CASE WHEN，缩进拉到底，改动一个分支都要靠IDE的高亮功能定位。这显然是滥用，不是一个合格从业者该留下的代码。

5.1 嵌套层数控制在两层以内

如果业务规则复杂到必须多层分支，考虑两种替代。第一种是预先在子查询里算中间标志字段：

WITH base AS ( SELECT user_id, CASE WHEN login_count = 0 THEN 'never_login' WHEN last_login_at < now() - interval '90 days' THEN 'dormant' ELSE 'active' END AS user_state, SIGN(amount) AS has_spend FROM users ) SELECT user_id, CASE WHEN user_state = 'active' AND has_spend = 1 THEN '核心用户' WHEN user_state = 'active' THEN '活跃未消费' WHEN user_state = 'dormant' THEN '沉睡用户' ELSE '新客' END AS user_level FROM base;

先算user_state和has_spend，再在前一层做组合判断，两层CASE就足够了，每一层只承担一个维度的语义。我碰到特别复杂的维度组合，往往直接把第二层也拆成第三个CTE，宁可SQL长一点，也不让大脑一次记十层条件。

第二种替代是用映射表JOIN。比如把订单状态码映射成状态名、再映射成统计分组，如果状态码本身有两三百个，CASE WHEN会写到手软，维护时还要通读全文。这时候一张status_map表，两列code和group_name，一个LEFT JOIN搞定，加映射只改表不碰SQL。CASE WHEN适合"规则少且稳定"的场景，不适合当字典表用。

5.2 CASE WHEN在更多SQL位置上的妙用

除了SELECT，CASE WHEN还能用在UPDATE、CHECK约束、ORDER BY这些容易被忽略的位置。

条件更新一个很常见的需求：订单表里只有已支付订单能修改实际支付金额，未支付的保持NULL。写成：

UPDATE orders SET paid_amount = CASE WHEN status = 'paid' THEN 150.00 ELSE paid_amount END WHERE order_id = 1024;

ELSE paid_amount保证了非目标状态行的值不动，这比先把所有行读到程序里判断再写回，安全且高效得多。

ORDER BY里做业务排序，比如列表页希望VIP用户排前面，普通用户按注册时间倒序：

SELECT username, vip_level FROM users ORDER BY CASE WHEN vip_level > 0 THEN 0 ELSE 1 END, created_at DESC;

这个用法在各大数据库里都很常见，但PostgreSQL有个额外讲究：ORDER BY里用了CASE表达式后，查询无法直接利用vip_level和created_at上的联合索引顺序，排序会在内存或临时文件里完成。数据量大时，可以考虑在结果集里增加一个rank字段再排序，或者用部分索引配合查询。

CHECK约束里的CASE WHEN不用太多，通常用来承载复杂的表约束条件，比如"当订单状态为取消时，取消原因必须填写"。这种情况用CHECK (CASE WHEN status = 'canceled' THEN cancel_reason IS NOT NULL ELSE TRUE END)表达非常紧凑，比一堆AND OR看着清楚。

5.3 字典映射时注意大小写、空格和NULL

用CASE WHEN做字典映射时，输入数据不会总是规规矩矩。'vip'、'VIP'、'Vip'如果都出现在数据里，直接WHEN col = 'vip'会漏掉一半。要么处理前统一大小写：

CASE WHEN LOWER(col) = 'vip' THEN 'VIP用户' WHEN LOWER(col) = 'common' THEN '普通用户' END

要么干脆建映射表。我的经验是：这种映射越复杂，越不应该用CASE WHEN硬撑。CASE WHEN处理的是"规则清晰的三五条分支"，不是"字典查询"。如果哪天业务告诉你又加了七八个映射值，我的第一反应不是往CASE里贴条件，而是思考是不是该抽一张维度表了。这是个判断力问题，写SQL写到后面，难的不是语法，是这种边界感。

6. 我踩过的坑：类型不一致、短路假设和排序结果异常

最后把几个真踩过的坑集中说一下。每个都花了不算短的时间定位，写出来能帮你省几小时。

6.1 CASE分支返回类型不一致，PostgreSQL直接甩错

CASE WHEN的各分支返回类型必须兼容。PostgreSQL在解析阶段就会做类型推导，如果THEN返回integer、ELSE返回text，会直接报错：

CASE WHEN flag = 1 THEN count_val ELSE status_desc END

这里count_val是integer，status_desc是text，PostgreSQL会报错，提示CASE类型不匹配。解决办法是把整数分支显式转成text：THEN count_val::text。反过来，如果多数分支是整数，少数是numeric，PG通常会自动提升为numeric，大多数情况下不用管，但涉及精度时最好手动指定一下目标类型。

这里有个和MySQL的差异：MySQL对类型容忍度高，经常隐式转换，比如把字符串常量悄悄转成数字；PostgreSQL更严格，宁可报错也不肯悄悄转换。我见过一个从MySQL迁移过来的统计脚本，线上跑了半年，某天新加了一个ELSE分支后，PostgreSQL在准备阶段直接报错，查了半天才发现就是新分支里混进一个字符串常量。从MySQL迁移过来的人，写CASE WHEN时最容易栽在这里。

6.2 别把CASE WHEN当成异常屏蔽器

前文提到过短路求值，这里说一下我的真实态度。CASE WHEN在绝大多数情况下是短路的——前面的WHEN命中，后面的分支不会计算。但SQL终究是声明式语言，优化器有权决定执行顺序，PostgreSQL也没有在文档里把"短路"作为一条面向用户的承诺。我见过有人把CASE ELSE写成1/0，想着"反正永远不会执行"，测试也确实过了，因为所有数据都命中了前面的WHEN。后来新业务加了新状态，新增数据走不到前面的分支，ELSE一执行就报除零错误。这种坑不是CASE WHEN设计有问题，而是拿它当异常防火墙用错了位置。

正确处理是让数据先干净。除法写成total / NULLIF(amount, 0)，把除零变成NULL；需要默认值再套COALESCE(total / NULLIF(amount, 0), 0)。语义清楚，优化器再怎么折腾，执行结果都不会变出异常来。

6.3 ORDER BY里CASE WHEN的排序结果可能与直觉不符

之前写ORDER BY CASE WHEN给业务排序，遇到过一个坑：排序值用了字符串而不是数值。业务觉得'A'排在'B'前面没问题，后来type种类多了，有人加了一个C分支，又想调整顺序。最稳妥的做法是排序字段用整数，展示映射交给SELECT里的CASE WHEN去处理。排序用数字等级，展示用文本标签，两个CASE WHEN各司其职，别混在一个表达式里。

还有一个容易忽视的点：PostgreSQL升序排序默认NULLS LAST，降序默认NULLS FIRST。如果CASE WHEN分支里有NULL，排序顺序可能完全反直觉。比如我想让type为NULL的行无论升降序都排在最后，就要显式写：

ORDER BY CASE WHEN type IS NULL THEN 1 ELSE 0 END, type ASC

这样的写法在业务排序里很稳，不管数据怎么变，NULL的位置都符合预期。

这些坑大多数不是CASE WHEN本身的问题，而是对PostgreSQL类型系统、NULL语义和执行计划理解不到位。CASE WHEN是标准SQL里少数能把"条件逻辑"直接塞进表达式的能力，用好它，报表和数据处理脚本能写得又短又清晰；用歪了，就是藏在SELECT列表里的定时炸弹。

最后再分享一个我自己的习惯：任何CASE WHEN表达式写完后，我都会顺手查一遍ELSE和NULL分支，再在测试数据里故意造一两条不满足任何WHEN条件的记录去验证。这个习惯帮我挡住过至少三次线上SQL事故，也希望你在复制代码去跑之前，先花三十秒做同样的事。