case在select中是返回值的表达式而非流程控制语句，必须显式写else，所有then分支类型需兼容，不可替代where过滤，简单case仅支持等值匹配，搜索case才支持布尔表达式和is null。
SELECT里用CASE实现逻辑判断，本质是表达式不是语句
CASE在SELECT中是表达式，返回一个值，不是控制流程的语句。它不能直接执行INSERT/UPDATE，也不能嵌套成“逻辑块”来替代WHERE或HAVING——很多人误以为写了CASE就能绕过过滤条件，结果查出一堆NULL或意外默认值。
常见错误现象：CASE WHEN status = 'active' THEN name END 导致其他status行返回NULL，而没意识到需要ELSE兜底；或者把CASE写在WHERE里当布尔条件用（SQL不支持）。
- 必须显式写
ELSE，否则不匹配时一律为NULL - 所有
THEN分支返回的数据类型要兼容，否则触发隐式转换甚至报错（比如THEN 1和THEN 'yes'在严格模式下可能失败） -
CASE不能替代索引友好的条件：把WHERE CASE...硬塞进过滤逻辑，会导致全表扫描
简单CASE vs 搜索CASE：选错就容易漏判
两种语法行为差异大，但名字太像，导致写错却不报错——只是结果不对。简单CASE是等值匹配（CASE column WHEN value THEN ...），搜索CASE才支持任意布尔表达式（CASE WHEN column > 10 THEN ...）。
使用场景：按范围分组（如分数划档）、多条件组合（如country = 'CN' AND level > 5）、空值特殊处理（WHEN col IS NULL）——这些只能用搜索CASE。
- 简单CASE不支持
IS NULL、比较运算符、函数调用，只认“=”，且会做类型强制转换 - 搜索CASE中每个
WHEN独立求值，顺序重要：前面条件为真，后面的就跳过（短路），所以高概率条件往前放能略提性能 - 别在简单CASE里写
WHEN column IN ('a','b')——语法错误，得改用搜索CASE
CASE结果参与排序或聚合时，NULL处理很关键
当CASE结果用于ORDER BY或GROUP BY，NULL会被当作一个独立分组或排在最前/最后（取决于数据库），极易造成统计偏差或排序错乱。
示例：想按用户等级分三档排序，但漏了ELSE，大量用户被归到NULL组，ORDER BY CASE...后看起来“没规律”。
- 在
ORDER BY中，加NULLS LAST（PostgreSQL/Oracle）或用COALESCE(CASE..., 999)兜底（MySQL/SQL Server） - 聚合时如
COUNT(CASE WHEN ... THEN 1 END)是安全的，但COUNT(CASE WHEN ... THEN col END)会忽略col为NULL的行——这不是BUG，是COUNT语义 - 避免在
GROUP BY里直接用无ELSE的CASE，否则NULL组可能吞掉你预期外的数据
跨数据库兼容性：ELSE不可省，但NULL处理策略不同
所有主流数据库都要求CASE有ELSE（即使写ELSE NULL），但对NULL在排序、聚合中的默认行为不一致。开发时本地跑通，上线到另一环境就出偏差，大概率栽在这儿。
比如MySQL 8.0默认ORDER BY ... NULLS FIRST，而PostgreSQL默认NULLS LAST；SQL Server不支持NULLS FIRST/LAST语法，只能靠CASE手动映射。
- 生产SQL尽量显式处理
NULL：用COALESCE或带ELSE的CASE统一转成占位值（如'unknown'或-1） - 避免依赖数据库默认的
NULL排序位置，尤其做分页或前端展示时 - 如果用到
LEAD/LAG等窗口函数再套CASE，注意某些旧版MySQL不支持窗口函数内嵌CASE的复杂写法
真正麻烦的不是写不对CASE，而是它“看起来运行了”，结果数据错得不明显——比如统计报表少算2%活跃用户，查半天发现是某个CASE漏了ELSE，把部分状态映射成了NULL，又被COUNT(*)悄悄吞掉了。
