说实话，很多人在SQL视图中写CASE WHEN的时候，总把它当成万能开关——又想用它做过滤，又想拿它控制流程，结果翻车翻得毫无悬念。其实核心就三条：CASE WHEN在视图里只能是表达式的角色，必须带AS别名，ELSE分支得显式写，逻辑一复杂，就赶紧往映射表上靠。咱们今天就把这些坑一个个踩明白。
视图里只能把CASE WHEN当表达式用，不能当控制语句
SQL视图的本质就是一段被保存的SELECT查询，它不支持IF、WHILE这些流程控制，也不允许CASE WHEN单独杵在那儿或者用来做行级过滤。你写的CASE WHEN status = 'A' THEN 'Active' ELSE 'Inactive' END AS status_label，必须老老实实待在SELECT列表里作为一列出现，否则数据库直接给你甩个语法错误。
常见的翻车点有这几个：
- 把CASE扔在WHERE里想搞“动态过滤”——比如
WHERE CASE WHEN type = 'U' THEN user_id ELSE admin_id END = 123，语法上能跑，但索引基本废掉。 - 在FROM后面单独写CASE却不带AS别名——数据库根本不知道这是个啥，报错位置还特别难找。
- 企图用CASE决定某行出现与否（比如只显示已审核订单）——这活儿该交给
WHERE audit_status = 'approved'，不是CASE。
多分支CASE逻辑一超过5个，就该考虑映射表
视图里堆上10个WHEN分支，看着挺能打，实际维护起来头疼，查询速度也受影响：每个分支都得逐行计算，优化器没法把条件往下推，大表上搞不好就是全表扫描。更麻烦的是类型不一致隐患——比如有的分支返回'VIP'，有的返回1，PostgreSQL直接报错，MySQL悄悄转成字符串，下游程序一解析就崩。
遇到这种情况，建议直接重构：
- 建一张
status_map表，字段包括type_code（主键）、label、sort_order，把硬编码变成可索引的物理表。 - 用
LEFT JOIN status_map ON t.status = m.type_code代替CASE，再用COALESCE(m.label, 'Unknown')模拟ELSE行为。 - 如果原CASE有优先级（比如多个条件可能同时匹配），靠
sort_order+ROW_NUMBER() OVER (PARTITION BY t.id ORDER BY m.sort_order)去重。
嵌套CASE和聚合里的CASE最容易漏ELSE
嵌套写法比如CASE WHEN score >= 90 THEN CASE WHEN score >= 95 THEN '特优' ELSE '优秀' END ELSE '非优秀' END，看起来够严密了吧？但只要外层没写ELSE，score为NULL时整列就变成NULL——这种坑特别隐蔽。再看聚合里写COUNT(CASE WHEN paid = 1 THEN 1 END)，它会把未支付的行直接跳过，因为COUNT不统计NULL，你实际得到的只是“已支付行数”，并非比例。
安全写法必须牢记：
- 所有CASE必须显式写
ELSE，哪怕只是ELSE ''或ELSE 0。 - 条件计数统一用
SUM(CASE WHEN paid = 1 THEN 1 ELSE 0 END)，确保每行都参与运算。 - 涉及NULL判断，必须写
WHEN score IS NULL THEN 'Missing'，不能写WHEN score = NULL。
WHERE里塞CASE等于主动放弃索引
语法上允许WHERE (CASE WHEN type = 'U' THEN user_id ELSE admin_id END) = 123，但绝大多数数据库不会对这种表达式走索引。优化器要么做全表扫描，要么生成临时结果集，数据量一超过10万行，响应时间立马变得肉眼可见地卡顿。
替代方案其实不复杂：
- 拆成OR条件：
WHERE (type = 'U' AND user_id = 123) OR (type != 'U' AND admin_id = 123)。 - 实在拆不开，并且字段有索引，可以考虑建函数索引（PostgreSQL：
CREATE INDEX ON t ((CASE WHEN type='U' THEN user_id ELSE admin_id END))；MySQL 8.0+ 类似，但需要确认版本）。 - 如果用映射表JOIN，直接在WHERE里过滤
m.label = 'Active User'，索引就能正常生效。
说到底，CASE WHEN的难点不在语法本身，而在类型一致性和NULL传导链——一个没写ELSE的CASE，可能让整列聚合值偏差30%，而你排查半天都找不到根儿。
