select中case when返回null的最常见原因是未写else且无when条件匹配，依据sql标准必须返回null而非报错；显式添加else可提升逻辑可控性与可读性。
CASE WHEN 不是函数，是表达式；直接在 SELECT 中写就能生效，但写错顺序或漏 ELSE 会导致 NULL 意外出现。
为什么 SELECT 中的 CASE WHEN 返回一堆 NULL？
最常见原因是没写 ELSE，而所有 WHEN 条件都不匹配——这时 SQL 标准规定返回 NULL，不是报错，所以容易被忽略。
- 显式写
ELSE NULL或ELSE '未知'，让逻辑意图可读且可控 - 条件顺序很重要：
WHEN age > 60放在WHEN age > 18前面，否则后者永远不触发 - 注意数据类型隐式转换：比如
WHEN status = 1 THEN 'active'和ELSE 0会强制把字符串转成数字（或反之），可能报错或截断
CASE WHEN 在 WHERE 和 ORDER BY 里也能用，但用法不同
CASE WHEN 在 WHERE 中不能直接“过滤分支”，但可以构造计算列参与判断；在 ORDER BY 中常用于自定义排序优先级。
-
WHERE中想按逻辑分组筛选？改用布尔表达式更清晰，比如WHERE (status = 'A' AND amount > 1000) OR (status = 'B' AND amount ，别硬套 <code>CASE -
ORDER BY中可用：ORDER BY CASE type WHEN 'Urgent' THEN 1 WHEN 'Normal' THEN 2 ELSE 3 END，避免写多个UNION - 聚合场景下，
CASE WHEN常和SUM/COUNT配合，比如COUNT(CASE WHEN paid = true THEN 1 END)统计已支付数
嵌套 CASE WHEN 容易写晕，优先拆成独立字段
三层以上嵌套不仅难读，还容易漏括号、错缩进，调试时连哪条分支生效都看不清。
- 把主干逻辑先用
CASE算出一个中间列（如category），再基于它二次分类，比一层里塞WHEN ... THEN CASE ... END清晰得多 - 某些数据库（如 PostgreSQL）支持
SELECT列别名在ORDER BY中直接引用，但不能在同级WHERE中用——嵌套时尤其要注意作用域 - MySQL 8.0+ 和 PostgreSQL 支持
SEARCHED CASE（即带布尔表达式的WHEN），但老版本 MySQL 只支持SIMPLE CASE（等值判断），写WHEN x > 0会直接报错：ERROR 1064 (42000)
真正麻烦的不是语法，而是当业务规则变多时，CASE 的维护成本指数上升。上线前务必用边界数据（空值、负数、超长字符串）跑一遍，不然生产环境里那个默默返回 NULL 的 ELSE 缺失，可能要花半天才定位到。
