CASE WHEN在SELECT中用于字段值转换最常用，WHERE中嵌套通常低效且应避免，聚合函数中用其条件计数/求和不可替代，嵌套时需注意END配对与缩进。
CASE WHEN在SELECT中做字段值转换最常用
直接在查询结果里按规则改写字段值，比如把数字状态码转成中文描述，或者对金额做分级打标。这时候用CASE WHEN最自然，不改变原始数据结构，只影响输出。
注意ELSE不是可选的——省略后遇到不匹配条件会返回NULL，容易导致前端展示异常或统计口径偏差。生产环境建议显式写ELSE '未知'这类兜底值。
示例：把用户等级字段level转成描述
SELECT name,
CASE WHEN level = 1 THEN '普通会员'
WHEN level = 2 THEN 'VIP'
WHEN level IN (3, 4) THEN 'SVIP'
ELSE '未定义等级'
END AS level_desc
FROM users;
WHERE子句里嵌套CASE WHEN通常没必要且低效
CASE WHEN本质是表达式，不是逻辑控制语句。在WHERE里强行用它做条件判断，往往说明设计思路有问题——多数情况可以直接用AND/OR组合，或拆成多个UNION ALL查询。
常见误用场景：想根据参数动态切换过滤条件。比如“如果传了@type就按type查，否则查全部”。这种应该用应用层拼SQL，或用IS NULL配合布尔逻辑：
- ✅ 推荐：
WHERE (@type IS NULL OR type = @type) - ❌ 避免：
WHERE type = CASE WHEN @type IS NOT NULL THEN @type ELSE type END（可能让索引失效）
聚合函数里用CASE WHEN实现条件计数/求和
这是CASE WHEN真正不可替代的场景。比如统计“支付成功订单数”“退款订单数”，不需要分多次查，一个SQL就能搞定。
关键点在于把CASE WHEN整个作为聚合函数的输入参数，而不是反过来。写错顺序会导致语法错误或结果全为0。
示例：按天统计各类订单金额
SELECT DATE(create_time) AS dt,
SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) AS paid_amt,
SUM(CASE WHEN status = 'refunded' THEN amount ELSE 0 END) AS refunded_amt,
COUNT(CASE WHEN score >= 4 THEN 1 END) AS high_score_cnt
FROM orders
GROUP BY DATE(create_time);
注意COUNT里用CASE时，匹配不到的行要返回NULL（不能写ELSE 0），否则COUNT(0)也会被计数。
嵌套CASE WHEN容易漏掉END或括号错位
多层嵌套时，每个CASE必须配对END，但很多人只记得最外层。数据库报错信息常是"missing keyword END"或"unexpected token"，其实只是某一层少写了END。
更隐蔽的问题是括号和缩进混乱，尤其当CASE里还混着COALESCE、NULLIF等函数时。建议：每层CASE单独缩进，END和对应CASE保持相同缩进级别；复杂逻辑优先拆成子查询或CTE。
一个典型陷阱：在THEN里再写CASE，但忘了给内层加END
-- 错误写法（缺一个END）
CASE WHEN a > 0 THEN
CASE WHEN b = 1 THEN 'x' ELSE 'y' -- 这里少了一个END！
ELSE 'z' END
实际执行时，数据库会一路报错到最外层，很难定位具体哪一层漏了END。
