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。