视图定义中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 条件，问题就会静默扩散到所有依赖该视图的报表和接口里。