CASE WHEN 不是函数，无返回类型推导、不支持链式调用；应区分简单型（仅等值判断）与搜索型（支持布尔表达式）；THEN 值须类型兼容，ELSE 必须显式写出；避免在 WHERE 中滥用，优先用原生布尔逻辑；GROUP BY/ORDER BY 需重复表达式或用子查询；NULL 与空字符串需显式分别判断；嵌套时注意 END 配对。
CASE WHEN 不是函数，别当函数用
它没有返回值类型自动推导，不支持链式调用，也不能像 IF() 那样直接嵌在表达式中间。写成 CASE (col) 或 CASE col WHEN ... END 混用简单/搜索型语法，是最常见的报错起点。
- 简单型只适用于“字段值 == 某个常量”的场景：
CASE status WHEN 'active' THEN 1 WHEN 'inactive' THEN 0 ELSE -1 END - 搜索型才支持完整布尔判断，95% 的业务逻辑该用它：
CASE WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' ELSE 'F' END - 所有
THEN后的值必须类型兼容——混用'yes'和1在 PostgreSQL 中会直接报错，MySQL 可能隐式转但结果不可控 -
ELSE必须显式写出，不写等价于ELSE NULL，后续做WHERE result = 'A'时会漏掉所有没匹配上的行
WHERE 里硬塞 CASE WHEN，八成是设计错了
数据库优化器很难对 CASE 包裹的条件生成有效索引计划，尤其是当 CASE 出现在等号左边时（如 CASE WHEN x > 10 THEN y ELSE z END = 5），基本等于放弃索引。
- 优先用原生布尔逻辑：
WHERE type = 'A' AND amount > 100 OR type = 'B' AND amount > 50 - 真要参数化控制过滤逻辑（比如后台开关），用应用层拼 SQL 或绑定参数更安全，例如：
WHERE created_at > ?，由代码传入不同时间值 - 唯一勉强可接受的例外：字段本身是计算列且无法提前物化，例如
WHERE CASE WHEN is_temp = 1 THEN temp_created ELSE created END > NOW() - INTERVAL '3 days'，但也建议拆成UNION ALL两个查询
GROUP BY / ORDER BY 引用 CASE 表达式必须字面一致
数据库不会“理解”你指哪个逻辑字段，它只认字符串完全匹配。写 SELECT CASE WHEN a > 1 THEN 'big' ELSE 'small' END AS size FROM t GROUP BY size 在 MySQL 可能侥幸通过，但在 PostgreSQL、SQL Server 中直接报错：“column "size" does not exist”。
- 正确做法只有两种：要么重复整个
CASE表达式：GROUP BY CASE WHEN a > 1 THEN 'big' ELSE 'small' END - 要么用子查询或 CTE 提前算好：
SELECT size FROM (SELECT CASE WHEN a > 1 THEN 'big' ELSE 'small' END AS size FROM t) s GROUP BY size - 别依赖别名，别省略空格和大小写——
CASE WHEN...和case when...在部分方言里被视为不同表达式
NULL 和空字符串必须手动判断，CASE 不会帮你兜底
CASE WHEN col = '' THEN 'empty' 对 NULL 无效；CASE WHEN col IS NULL THEN 'null' 对空字符串也无效。两者语义完全不同，漏判一个就可能让统计口径出偏差。
- 显式合并判断：
CASE WHEN col IS NULL OR col = '' THEN 'missing' WHEN col = 'N/A' THEN 'not_applicable' ELSE col END - 避免用
=比较 NULL，永远用IS NULL或IS NOT NULL - 如果字段允许 NULL，且业务上 NULL 和空字符串含义一致，建议在应用层或 ETL 阶段统一清洗，别把歧义留到查询时处理
最易被忽略的是嵌套 CASE 的 END 配对——每个 CASE 必须有且仅有一个对应的 END，少一个或错位一个，整条 SQL 就解析失败，而且错误提示往往指向末尾而非真实缺位处。
