视图中CASE WHEN与普通SELECT语法一致，但需显式别名、不可用于WHERE过滤、必须写ELSE防NULL、嵌套不宜超三层，且类型不一致在运行时才报错更难定位。
视图里写CASE WHEN和普通SELECT没区别，但得注意定义时的约束
视图本质是保存的查询语句，CASE WHEN 只要语法合法、字段类型一致，就能直接用。但视图创建时不会校验数据，只校验语法——所以运行时报错（比如类型不匹配）往往比在SELECT里更难定位。
- 必须显式给
CASE WHEN结果列起别名，否则视图字段名会是case或expr这类默认名，后续引用容易出错 -
ELSE分支不能省略，除非你明确接受NULL——尤其当该列被下游程序当作非空字段使用时 - 如果视图用于报表或BI工具，注意某些工具对嵌套
CASE WHEN或超长表达式支持有限，可能截断或解析失败
WHERE子句里用CASE WHEN？不行，得改写成逻辑表达式
视图定义中，CASE WHEN只能出现在SELECT列表、ORDER BY或GROUP BY里，**不能直接放在WHERE条件中作为过滤逻辑**。常见错误是这么写：
CREATE VIEW v_user_level AS SELECT id, name, CASE WHEN score >= 90 THEN 'A' ELSE 'B' END AS level FROM users WHERE CASE WHEN score >= 90 THEN 'A' ELSE 'B' END = 'A'; -- ❌ 语法错误
正确做法是把条件还原为原始字段逻辑：
CREATE VIEW v_user_level AS SELECT id, name, CASE WHEN score >= 90 THEN 'A' ELSE 'B' END AS level FROM users WHERE score >= 90; -- ✅ 用score字段本身过滤
嵌套CASE WHEN在视图里很容易失控，优先拆成计算列
三层以上嵌套的CASE WHEN会让视图难以维护，也影响可读性。比如按分数+活跃度双重定级：
CASE WHEN score >= 90 THEN CASE WHEN last_login_days < 7 THEN 'VIP' ELSE 'GOLD' END WHEN score >= 60 THEN CASE WHEN last_login_days < 7 THEN 'SILVER' ELSE 'BRONZE' END ELSE 'INACTIVE' END
不如拆成两个视图字段或用CTE预处理：
SELECT id, name,
CASE WHEN score >= 90 THEN 'A'
WHEN score >= 60 THEN 'B'
ELSE 'C' END AS score_level,
CASE WHEN last_login_days < 7 THEN 'ACTIVE' ELSE 'INACTIVE' END AS activity_status
FROM users;后续再用score_level和activity_status组合判断，逻辑更清晰，也方便索引优化。
MySQL/PostgreSQL/SQL Server对视图中CASE WHEN的兼容性差异很小，但NULL处理要盯紧
所有主流数据库都支持视图里用CASE WHEN，真正容易踩坑的是NULL传播规则：
- 如果
score字段本身允许NULL，CASE WHEN score >= 90 THEN 'A' ELSE 'B' END会把NULL归入ELSE分支 → 返回'B'，这通常不是你想要的 - 正确写法是显式处理
NULL：CASE WHEN score IS NULL THEN 'N/A' WHEN score >= 90 THEN 'A' ELSE 'B' END - PostgreSQL对类型推导更严格，
THEN 'A'和ELSE 0会直接报错；MySQL可能隐式转成字符串，但结果不可靠
视图一旦创建，字段类型就固定了。哪怕源表字段类型变了，视图定义也不会自动更新——这点比临时SELECT更隐蔽，也更危险。
