嵌套CASE需严格匹配END，缩进仅助读；WHEN支持布尔表达式；超两层嵌套建议用CTE或子查询；GROUP BY/ORDER BY中CASE须与SELECT列完全一致；NULL需显式判断；ELSE不写默认返回NULL。
多个 WHEN 分支里怎么写嵌套逻辑
直接在 WHEN 后面写另一个 CASE 是完全合法的，但容易漏掉最外层的 END —— 每个 CASE 都必须有且仅有一个对应的 END，嵌套时缩进不解决语法问题，只解决人眼问题。
常见错误现象：SQL Error: ORA-00905: missing keyword 或 PostgreSQL: ERROR: syntax error at or near "CASE"，往往是因为内层 CASE 写完没关，外层又多写了个 END。
- 推荐把每个
CASE单独换行、缩进对齐，像写代码一样对待 - MySQL 8.0+ 和 PostgreSQL 支持在
WHEN条件中直接用布尔表达式（如WHEN status = 'active' AND created_at > '2023-01-01'），不用硬套CASE - 如果嵌套超过两层，考虑先用子查询或 CTE 把中间状态算出来，可读性和执行计划都更可控
SELECT id,
CASE
WHEN type = 'user' THEN
CASE
WHEN is_premium = 1 THEN 'vip'
ELSE 'basic'
END
WHEN type = 'admin' THEN 'staff'
ELSE 'unknown'
END AS role_label
FROM accounts;
CASE 用在 GROUP BY 或 ORDER BY 里为什么报错
CASE 可以出现在 GROUP BY 和 ORDER BY 中，但必须和 SELECT 列表里的表达式完全一致（字面量级一致），否则多数数据库会拒绝执行。
使用场景：按业务规则分组（比如把订单金额 'draft' 排）。
- PostgreSQL 允许直接写
ORDER BY CASE status WHEN 'draft' THEN 1 ... END，但 MySQL 要求该表达式必须出现在SELECT列表中（哪怕用别名，哪怕加AS dummy） - SQL Server 对
GROUP BY CASE更宽松，但若CASE包含聚合函数（如COUNT(*)），就会报错：不能在GROUP BY里用聚合 - 别在
GROUP BY里写带NULL处理的CASE然后忘了ELSE—— 缺失ELSE会让默认返回NULL，而多个NULL在分组中是否合并，各数据库行为不一致（PostgreSQL 合并，MySQL 5.7 默认不合并）
WHERE 里用 CASE 代替 AND/OR 容易出什么问题
能用 AND/OR 实现的条件，就别硬套 CASE。不是语法不行，而是优化器大概率放弃走索引，尤其当 CASE 出现在 WHERE 左侧（如 CASE WHEN x > 0 THEN y ELSE z END = 5）。
性能影响：这类写法几乎必然导致全表扫描，因为数据库无法将该表达式下推到索引结构中做范围判断。
- 正确做法是拆成
UNION ALL（如果分支互斥）或用标准布尔逻辑重写 - 如果真要动态过滤（比如搜索框支持“按姓名/邮箱/手机号任意一项匹配”），优先考虑应用层拼 SQL，而不是靠
CASE在数据库里兜底 - SQLite 会静默接受
WHERE CASE ... END = ?，但执行计划里显示SCAN TABLE—— 它根本没尝试用索引
NULL 值在 CASE 的 WHEN 和 ELSE 之间怎么流转
CASE 表达式本身不会把 NULL 当作“未命中”来触发 ELSE；它只看 WHEN 后的布尔判断结果是不是 TRUE。NULL = NULL 返回 NULL（不是 TRUE），所以不会进入那个分支。
容易踩的坑：以为写了 WHEN col IS NULL THEN ... 就万事大吉，结果发现 col 是空字符串或空白字符，而你没覆盖这个 case。
- 显式判断
WHEN col IS NULL OR TRIM(col) = ''才真正涵盖“无值”场景 -
ELSE不写的话，默认返回NULL，但某些旧版 Hive 或 Impala 会报错，要求必须有ELSE - 在聚合上下文中（如
SUM(CASE WHEN ... THEN value END)），没匹配的行会贡献NULL，而SUM自动忽略NULL—— 这是好行为，但别误以为是ELSE 0的效果
