CASE WHEN必须用于SELECT等子句生成新值，不可放在WHERE中；需写ELSE避免NULL；各THEN分支类型应一致；复杂逻辑宜拆分为独立字段而非嵌套。
SELECT中用CASE WHEN做字段值映射，别写成WHERE条件
很多人一想到“条件判断”就下意识往WHERE里塞逻辑，但CASE WHEN是表达式，必须放在SELECT（或ORDER BY、GROUP BY）里才能生成新值。写在WHERE里会直接报错：ERROR: syntax error at or near "CASE"。
典型场景：把数字状态码转成中文描述，比如status = 1显示“已支付”，status = 0显示“未支付”。
- 必须用
SELECT CASE WHEN status = 1 THEN '已支付' WHEN status = 0 THEN '未支付' ELSE '未知' END AS status_text -
ELSE不是可选的——没写且遇到不匹配的值，结果就是NULL，容易引发前端空指针或报表断层 - 所有
THEN分支返回的数据类型要尽量一致；混用字符串和数字（如THEN 1和THEN 'active'）可能触发隐式转换，MySQL里会转成字符串，PostgreSQL则直接报错ERROR: CASE types integer and text cannot be matched
嵌套CASE WHEN不如拆成多个独立字段，尤其涉及聚合时
想在一个CASE WHEN里同时判断地区、金额、时间三个维度？可以，但很快会变成难以维护的“俄罗斯套娃”。更稳妥的做法是：每个业务维度单独建一个计算字段。
例如统计各城市高价值客户数（订单额 > 5000）和新客数（注册时间在2024年之后）：
SELECT city, COUNT(*) FILTER (WHERE order_amount > 5000) AS high_value_count, -- PostgreSQL COUNT(*) FILTER (WHERE registered_at > '2024-01-01') AS new_user_count FROM users u JOIN orders o ON u.id = o.user_id GROUP BY city;
如果数据库不支持FILTER（如MySQL），就用独立CASE WHEN：
SELECT city, SUM(CASE WHEN order_amount > 5000 THEN 1 ELSE 0 END) AS high_value_count, SUM(CASE WHEN registered_at > '2024-01-01' THEN 1 ELSE 0 END) AS new_user_count FROM users u JOIN orders o ON u.id = o.user_id GROUP BY city;
- 避免
CASE WHEN (region = 'CN' AND amount > 5000 AND created > '2024') THEN ...这种长条件——调试时根本分不清哪段逻辑生效了 - 聚合函数（
SUM、COUNT）里套CASE WHEN必须配ELSE 0，否则NULL会被忽略，导致计数偏小
WHERE中想用CASE逻辑？改用布尔表达式或CTE预处理
CASE WHEN不能直接出现在WHERE的条件位置，但等价逻辑完全可以重写。比如“查出状态为1或2，且如果是2则必须创建时间超过30天”的需求：
- ❌ 错误写法：
WHERE CASE WHEN status = 2 THEN created_at → 语法错误 - ✅ 正确写法：
WHERE (status = 1) OR (status = 2 AND created_at - 更复杂逻辑建议先用CTE提取中间结果：
WITH enriched AS (SELECT *, CASE WHEN status = 2 THEN created_at ，再<code>SELECT * FROM enriched WHERE meets_condition
硬套CASE WHEN到WHERE里，本质是把控制流当成了过滤条件，反而掩盖了真实的数据筛选意图。
性能陷阱：CASE WHEN本身不慢，但滥用会导致索引失效
CASE WHEN表达式计算开销极小，真正拖慢查询的是它常伴随的全表扫描。比如：SELECT *, CASE WHEN email LIKE '%@gmail.com' THEN 'gmail' ELSE 'other' END FROM users——这个LIKE前缀通配符让email索引完全失效。
- 把
CASE WHEN里涉及的字段判断尽量前置到WHERE中（如先WHERE email IS NOT NULL再进CASE） - 避免在
CASE WHEN中调用函数做判断（如WHEN YEAR(created_at) = 2024），这会让created_at索引失效；改用范围查询：WHERE created_at >= '2024-01-01' AND created_at - 如果某类CASE逻辑高频使用（如状态码映射），考虑在表里加一个持久化计算列（MySQL 5.7+ 支持
GENERATED COLUMN，PostgreSQL 支持STORED生成列），并为其建索引
最常被忽略的一点：开发时只关注结果对不对，上线后才发现加了CASE的查询从100ms涨到2s——问题往往不出在CASE本身，而在它悄悄干掉了索引。
