SQL视图中CASE WHEN必须置于SELECT列表作为字段表达式，不可独立存在；需注意NULL处理、类型一致性及WHERE中使用可能引发全表扫描。
SQL视图里写CASE WHEN，必须放在SELECT列表里
视图本质是保存的查询语句，不能像存储过程那样写独立逻辑块。所有条件转换都得塞进 SELECT 子句中，作为字段表达式存在。你不能在 FROM 或 WHERE 之后单独“执行”一个CASE，它必须绑定到某个列上。
常见错误是把CASE写在视图定义末尾、或试图用它控制整个行是否出现——这不行，视图不支持行级条件过滤逻辑（那该用 WHERE）。
-
CASE WHEN status = 'A' THEN 'Active' WHEN status = 'I' THEN 'Inactive' ELSE 'Unknown' END AS status_label是合法写法 - 把
CASE单独一行写在FROM后面，不跟AS和别名 → 语法报错 - 想用CASE决定是否返回某行（比如只留status='A'的记录）→ 应该用
WHERE status = 'A'，不是CASE
NULL处理不当会让CASE结果意外变NULL
CASE 表达式只要任意分支结果为 NULL，且没有 ELSE，整列就会变成 NULL。更隐蔽的是：当比较字段本身为 NULL 时，= 判断永远不成立，直接跳过所有 WHEN 分支，最终走 ELSE；如果没有 ELSE，就返回 NULL。
- 写法
CASE WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' END：如果score是NULL，结果就是NULL，不是空字符串 - 安全写法：加上
ELSE ''或ELSE 'N/A' - 要显式匹配NULL，得写
CASE WHEN score IS NULL THEN 'Missing' WHEN score >= 90 THEN 'A' ... END，不能写WHEN score = NULL
在WHERE里嵌套CASE可能触发全表扫描
虽然语法允许在 WHERE 中用 CASE（比如 WHERE (CASE WHEN type='U' THEN user_id ELSE admin_id END) = 123），但多数数据库无法对该表达式有效走索引。优化器通常放弃使用索引，转为逐行计算，尤其在大表上性能陡降。
- 优先考虑拆成
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+ 支持函数索引，但需确认版本；旧版 MySQL 基本只能靠重写逻辑
视图中CASE的类型一致性影响下游应用
数据库会根据所有 THEN 和 ELSE 分支的结果推导整列的数据类型。如果分支返回 INT、VARCHAR(5)、DATE 混合类型，数据库会隐式转成最宽泛类型（通常是 VARCHAR），可能导致下游程序解析失败或精度丢失。
- 避免混用类型：
CASE WHEN flag THEN 1 ELSE 'N'→ 强制统一为字符串：CASE WHEN flag THEN 'Y' ELSE 'N' - 数值类转换建议显式转类型：
CASE WHEN qty > 0 THEN CAST(qty AS DECIMAL(10,2)) ELSE 0.00 END - PostgreSQL 对类型推导更严格，可能直接报错；SQL Server 和 MySQL 更倾向隐式转换，但行为不可控
视图里的 CASE WHEN 看似简单，真正麻烦的是它和索引、类型系统、NULL 语义的耦合——这些地方一动，线上查询可能突然慢几秒，或者报表数字对不上。写完务必用 EXPLAIN 看执行计划，再拿真实 NULL 数据跑一遍结果。
