CASE WHEN不是函数而是SQL标准条件表达式，必须用块状结构且不可省略END；常见错误包括误当函数调用、缺END、漏WHEN/THEN、类型不一致；两种写法中搜索型更通用，简单型仅限等值匹配。
CASE WHEN 不是函数，是 SQL 标准里的条件表达式，不能像 ROUND() 或 COALESCE() 那样直接套用参数调用。
为什么写 CASE WHEN 总报语法错误？
常见错误是把它当函数用，比如写成 CASE WHEN(condition, then_value, else_value) —— 这在任何主流数据库（PostgreSQL、MySQL、SQL Server、Oracle）里都会报错。它必须是块状结构，且 END 不能省略。
- 缺
END：直接报错，提示“unexpected end of input”或类似语法错误 - 漏
WHEN或THEN：解析失败，尤其在嵌套时容易少写一层THEN - 类型不一致：
THEN后面的值类型最好统一，否则某些数据库（如 PostgreSQL）会隐式转换失败，MySQL 可能转成字符串导致数值比较出错
CASE WHEN 的两种写法适用场景怎么选？
简单比较用「搜索型」，字段计算/表达式判断用「简单型」——但别死记，看实际需求更靠谱：
-
简单型（
CASE column_name WHEN value THEN ...）：只适合等值判断，比如CASE status WHEN 'A' THEN 'Active' WHEN 'I' THEN 'Inactive'；不支持>、IS NULL、函数调用 -
搜索型（
CASE WHEN condition THEN ...）：所有逻辑都走这条路，比如CASE WHEN price > 100 THEN 'expensive' WHEN price IS NULL THEN 'unknown'；条件从上到下匹配，第一个为真就返回，后续忽略
多数业务逻辑复杂时，直接用搜索型，避免来回切换写法造成混乱。
嵌套 CASE WHEN 容易掉进哪些坑？
嵌套本身合法，但可读性和维护性会快速下降，尤其在报表或 ETL 场景中：
- 缩进不一致导致逻辑错位：建议每层
WHEN对齐，END和对应CASE垂直对齐（哪怕 SQL 编辑器不自动格式化） - 忘记外层
ELSE：内层有ELSE不代表外层安全，漏写可能让整行变成NULL，而你查半天才发现是默认值没兜底 - 性能隐患：嵌套过深（比如 5 层以上）在 MySQL 8.0 以前可能触发优化器退化，PostgreSQL 通常还好，但依然建议拆成 CTE 或临时列
示例（安全写法）：
CASE WHEN user_type = 'vip' THEN<br> CASE WHEN order_count > 10 THEN 'top_vip' ELSE 'regular_vip' END<br>ELSE 'normal' END
和 COALESCE()、NULLIF() 混用时要注意什么？
它们不是替代关系，而是协作关系：CASE WHEN 负责多分支逻辑，COALESCE() 适合处理「取第一个非 NULL 值」这种扁平需求，NULLIF() 是二元快捷写法。
- 别用
CASE WHEN x IS NOT NULL THEN x ELSE y END替代COALESCE(x, y)—— 冗余且难读 -
NULLIF(a, b)等价于CASE WHEN a = b THEN NULL ELSE a END，但前者更简洁，也更易被优化器识别 - 混合使用时，注意运算优先级：比如
COALESCE(CASE WHEN ... END, 'default')没问题，但CASE WHEN COALESCE(x, y) > 0 THEN ...要确认x和y类型是否可比
真正复杂的判断，还是得靠 CASE WHEN；想偷懒绕开它，最后往往要花更多时间 debug。
