视图定义中CASE WHEN必须是完整可求值表达式，严格遵循“条件判断→结果返回→END收尾→AS别名”结构，漏END、错放AS、类型不一致或省略ELSE均会导致语法错误或NULL隐患。
视图定义里CASE WHEN必须写完整表达式，不能只写逻辑
在视图中用 CASE WHEN 转换状态，不是“加个判断就行”，它必须是完整、可求值的表达式，且要显式结束、命名。常见错误是漏 END 或把 AS 写进 CASE 里面，比如：CASE WHEN status = 1 THEN '已通过' AS status_desc END —— 这会直接报语法错。
正确写法必须严格遵循：条件判断 → 结果返回 → END 收尾 → AS 别名。视图一旦创建，这个表达式就固化为列的一部分，后续查询无法绕过它。
-
CASE WHEN是表达式，不是语句，不能单独存在；必须嵌在SELECT列表中 - 每个
WHEN后的THEN结果类型必须一致（比如全是字符串），否则 MySQL/PostgreSQL 会隐式转类型，但 SQL Server 可能直接报错 - 视图中不建议用子查询或函数包裹
CASE（如(SELECT ...)），会导致无法下推过滤、性能下降
简单CASE适合等值映射，搜索CASE才支持范围和多列判断
如果状态字段是整数编码（如 order_status INT），且只是 0→'待处理'、1→'已发货' 这类一一对应，优先用简单 CASE order_status WHEN 0 THEN '待处理' WHEN 1 THEN '已发货' ELSE '未知' END AS status_label。它更轻量，优化器也更容易识别索引使用机会。
但真实业务里，状态常依赖多个字段或范围逻辑——比如“支付成功且发货超48小时未签收 → 逾期风险”。这种必须用搜索 CASE：
CASE
WHEN payment_status = 1 AND shipped_at IS NOT NULL AND NOW() - shipped_at > INTERVAL '48 HOUR'
THEN '逾期风险'
WHEN payment_status = 1 AND delivered_at IS NOT NULL
THEN '已完成'
ELSE '其他状态'
END AS business_status- 搜索
CASE的条件可以含函数、比较符、多表字段，但注意：含函数的条件（如NOW() - shipped_at）无法走索引，别放在WHERE中依赖它过滤 - 简单
CASE不支持BETWEEN、LIKE、IS NULL等，强行用会语法报错 - MySQL 5.7 对简单
CASE的类型推断较弱，若status是TINYINT，WHEN '1'（字符串）可能不匹配，务必写WHEN 1
视图里不写ELSE会悄悄返回NULL，BI工具里常变成空格或乱码
很多视图上线后发现某几行“状态”列是空的，查了半天才发现是 CASE 没写 ELSE，遇到未覆盖的状态值就默认返回 NULL。而 Excel、Tableau 等工具对 NULL 渲染不一致：有的显示空白，有的显示 (null)，还有的直接报错无法聚合。
- 必须显式写
ELSE '未知状态'，别依赖“反正不会出现”这种假设——上游数据总有脏数据、迁移遗漏或新状态未同步 -
ELSE的值类型要和所有THEN保持一致；如果其他都是中文字符串，ELSE 0会导致整列被转成字符串'0'，但语义已丢失 - PostgreSQL 对类型一致性最严格，MySQL 有时会静默转，SQL Server 则可能在某些兼容模式下把
NULL转成空字符串，行为不可控
别在视图里嵌套太深，5层以上CASE会让执行计划变脆弱
有人为了“一劳永逸”，在视图里把用户等级、积分状态、风控标签全塞进一个 CASE，嵌套七八层。结果是：查询变慢、执行计划不稳定、DBA 查问题时一眼看不出逻辑主干。
- 单个
CASE嵌套超过 5 层，MySQL 优化器可能放弃常量折叠，PostgreSQL 的计划器也可能生成次优路径 - 更稳妥的做法是拆成多个独立
CASE列（如user_tier、risk_flag），让调用方按需选择，而不是强绑在一起 - 如果真需要复合判断，优先考虑用 CTE 或物化视图预计算，而不是在每一层查询里实时算
视图里的 CASE WHEN 最容易被当成“写完就扔”的一次性逻辑，但其实它会长期影响下游所有查询的稳定性——尤其是当原始字段含义变更、新状态加入时，漏掉一个 WHEN 条件，问题就会静默扩散到所有依赖该视图的报表和接口里。
