case when必须配对end，when后接布尔表达式，then后为标量值或字段名，强烈建议加else防null；where中不可直接用case when作条件，需改写为标准布尔逻辑。
SELECT 中的 CASE WHEN 语法怎么写才不出错
直接上最常用、最不容易翻车的写法：CASE WHEN 必须配对 END，且每个 WHEN 后面跟的是布尔表达式，不是字段名或别名。常见错误是漏掉 END，或者在 THEN 后面写带引号的字段名（比如 THEN 'user_name'），结果返回的是字面字符串，不是字段值。
正确结构如下：
SELECT
id,
CASE WHEN status = 1 THEN '已启用'
WHEN status = 0 THEN '已禁用'
ELSE '未知'
END AS status_label
FROM users;
-
WHEN条件支持任意合法表达式，比如created_at > '2024-01-01'、price IS NULL -
THEN后必须是单个标量值：字符串、数字、NULL，或一个确定的列（如THEN user_name） -
ELSE不是必须的，但强烈建议加上，否则NULL值或不匹配条件时会返回NULL，容易被前端误判
WHERE 里能用 CASE WHEN 吗？不能直接用，但可以绕过
CASE WHEN 是表达式，不是逻辑谓词，所以不能直接写在 WHERE 后当条件用，比如 WHERE CASE WHEN type = 'A' THEN price > 100 ELSE price > 50 END 在多数数据库（MySQL、PostgreSQL、SQL Server）中会报语法错误或语义错误。
真正可行的方式是把逻辑拆成标准布尔表达式：
WHERE (type = 'A' AND price > 100) OR (type != 'A' AND price > 50)
- 如果分支特别多，可先用子查询或 CTE 把
CASE计算成新列，再在WHERE中引用该列 - 注意：某些数据库（如 Oracle）允许在
WHERE中用CASE，但行为不一致，跨库迁移时极易出问题，不推荐依赖
性能影响：CASE WHEN 会让查询变慢吗
单纯在 SELECT 列表里用 CASE WHEN 几乎不影响执行计划和性能——它只是对已查出的行做一次计算映射。但有三个实际坑点：
- 如果
WHEN条件里用了函数（比如WHEN UPPER(name) = 'ADMIN'），会导致无法走name字段上的索引 - 嵌套太深（超过 5 层
CASE）可能让优化器放弃某些估算路径，尤其在 PostgreSQL 中会影响行数预估 - 在
ORDER BY或GROUP BY中使用CASE表达式，可能触发文件排序（Using filesort）或临时表，比直接按字段排序更耗资源
NULL 值处理：为什么 ELSE 没生效
最容易忽略的一点：WHEN 的判断是严格三值逻辑（TRUE/FALSE/UNKNOWN）。如果 status 是 NULL，那么 status = 1 结果是 UNKNOWN，不会进任何 WHEN 分支，最终落到 ELSE —— 这看似合理，但很多人忘了 NULL = NULL 也是 UNKNOWN，所以 WHEN status IS NULL 才是判断空值的正确写法。
示例：
CASE WHEN status IS NULL THEN '待审核'
WHEN status = 1 THEN '通过'
WHEN status = 0 THEN '拒绝'
ELSE '异常状态'
END
漏掉 IS NULL 显式判断，就等于把所有 NULL 都塞进 ELSE，而你可能以为它们“没匹配上”，其实只是 SQL 的空值语义在起作用。
复杂点在于，不同数据库对空值比较的默认行为略有差异，比如 SQL Server 的 ANSI_NULLS OFF 模式下 NULL = NULL 会返回 TRUE，但这种模式已被标记为弃用。统一用 IS NULL 最安全。
