CASE WHEN是SQL视图中实现条件分支唯一可靠且跨数据库兼容的方案，必须用于SELECT、ORDER BY或HAVING中生成计算列，不可用于WHERE过滤，需注意类型一致、显式ELSE及避免非确定性函数。
在 SQL 视图中实现条件分支，CASE WHEN 是唯一可靠、跨数据库兼容的方案；它不是“权宜之计”，而是 SQL 标准定义的表达式，直接嵌入 SELECT 列即可生效。
视图里不能用 IF 或 WHERE 做字段级判断
视图本质是预定义的查询语句，不支持存储过程式的流程控制（如 IF、WHILE），也不允许在 WHERE 子句中写 CASE 来“过滤字段值”——那会报错或逻辑错乱。常见误写：
SELECT * FROM orders WHERE CASE WHEN status = 1 THEN TRUE ELSE FALSE END;
这在 PostgreSQL/MySQL 中语法不合法，在 SQL Server 中虽能解析，但实际等价于 WHERE TRUE 或常量，起不到预期过滤作用。
正确做法只有一条：把 CASE WHEN 当作一个“计算列”，放在 SELECT 列表里：
-
CASE必须出现在SELECT、ORDER BY或HAVING中，不能独立成句 - 想按条件分组统计？用
CASE配合SUM或COUNT，例如SUM(CASE WHEN paid = 1 THEN 1 ELSE 0 END) - 想动态生成状态描述？直接
CASE WHEN status = 1 THEN '待处理' ... END AS status_text
简单 CASE 和搜索 CASE 的适用场景差异
两种写法底层能力不同，选错会导致逻辑僵化或漏判：
简单 CASE dept_no WHEN 'd001' THEN '市场部' 只做等值匹配，适合枚举型字段（如状态码、类型编码）。一旦需要范围判断（如 amount > 10000）或组合条件（如 status = 1 AND is_deleted = 0），必须用搜索型 CASE WHEN：
SELECT order_id,
CASE
WHEN total_amount > 50000 THEN 'VIP'
WHEN total_amount > 10000 THEN '大客户'
WHEN total_amount > 0 THEN '普通客户'
ELSE '无效订单'
END AS customer_tier
FROM orders;注意点：
- 条件顺序重要：数据库自上而下匹配，
WHEN total_amount > 0若写在最前，后面所有分支都不会执行 - 简单 CASE 无法处理
NULL：字段为NULL时，所有WHEN value都不匹配，必须靠ELSE捕获 - 搜索 CASE 可显式写
WHEN column IS NULL，更可控
容易被忽略的类型一致性与 NULL 风险
分支返回值类型不一致，会在某些数据库中直接报错，不是警告：
PostgreSQL 报错示例：column "level" has type text but expression has type integer，源于这样写：
CASE WHEN score > 90 THEN 'A' ELSE 0 END
解决方案很实在：
- 全部转字符串：
ELSE '0'或用CAST(0 AS TEXT) - 全部转数字：
ELSE 0.0，并确保所有THEN分支返回数值（如THEN 95.0） - 始终写
ELSE：不写时默认返回NULL，前端展示可能空白、BI 工具聚合异常、导出 Excel 出现空单元格 - 对原始字段含
NULL的情况单独判断，例如：WHEN amount IS NULL THEN '未录入'
物化视图或缓存场景下别调非确定性函数
在 PostgreSQL 物化视图、MySQL 查询缓存、或某些 BI 工具的预计算视图中，如果 CASE 里用了 NOW()、RANDOM()、UUID() 等非确定性函数，会导致每次刷新结果不一致，甚至缓存失效或数据错乱。
比如这个写法看着合理，实则危险：
CASE WHEN created_at > NOW() - INTERVAL '7 days' THEN '本周新增' ... END
修复方式很简单：
- 把时间逻辑移到应用层或外部参数传入（如用
$today占位符，由调用方代入具体日期） - 若必须在视图内固化时间点，改用确定性表达式，例如
CURRENT_DATE（注意：它仍是会变的，但至少每天稳定一次；真正静态需靠外部注入） - 涉及实时性要求高的分支，考虑不用视图，改用带参数的 CTE 或应用层计算
最常被跳过的细节是：你以为加了 ELSE 就安全了，但没检查各分支返回值是否同类型；还有人以为 CASE 能塞进 WHERE，结果查了半天发现根本没生效——这些都不是配置问题，是 SQL 表达式语义本身的硬约束。
