case when在select中必须确保各分支返回同类型值且显式写出else，否则易因类型混用或null引发报错；where中虽语法支持但应慎用，避免索引失效；group by中嵌套需与select完全一致。
CASE WHEN在SELECT中怎么写才不会报错
直接在SELECT里用CASE WHEN是最常见也最容易出错的场景。核心原则是：每个WHEN分支必须返回同类型值，且ELSE最好显式写出，否则遇到NULL可能引发隐式转换问题。
常见错误现象：ERROR: column "xxx" does not exist——其实是某个WHEN分支里引用了未出现在FROM子句中的字段；或者cannot cast type text to integer——不同分支返回了TEXT和INT混用。
-
CASE WHEN order_status = 'paid' THEN 1 WHEN order_status = 'cancelled' THEN 0 ELSE -1 END AS status_code（推荐：所有分支都是整数） - 避免：
CASE WHEN flag THEN 'true' ELSE 0 END（字符串和数字混用，PostgreSQL会报错，MySQL可能静默转成0） - 别漏
ELSE：没写时默认为NULL，但下游程序可能不处理NULL，导致空指针或聚合异常
WHERE里能用CASE WHEN吗？什么时候该用它
能在WHERE里用，但多数时候不该用——它会让条件失去索引能力。真正需要它的典型场景是：多字段动态匹配、权限过滤逻辑复杂、或需根据某字段值决定用哪个字段做判断。
例如用户表有role字段，管理员看全部数据，普通用户只能看自己创建的记录，这时：
WHERE CASE WHEN ? = 'admin' THEN 1 ELSE (created_by = ?)::int END = 1
但更推荐拆成两个查询，或用OR逻辑（如role = 'admin' OR created_by = ?），后者更容易走索引。
- 慎用在
WHERE里做计算：比如CASE WHEN EXTRACT(YEAR FROM order_date) = 2023 THEN ...——这会让order_date索引失效 - 如果必须用，确保
CASE只用于选择过滤字段，而非对字段做函数运算 - MySQL 8.0+ 和 PostgreSQL 支持在
WHERE中用CASE，但 SQLite 不支持
GROUP BY里嵌套CASE WHEN为什么结果不对
本质问题是：GROUP BY里的CASE WHEN必须和SELECT里的完全一致，否则分组逻辑断裂。很多人复制粘贴时漏改一个分支，或者用了别名但GROUP BY没同步更新。
典型错误：写完SELECT CASE WHEN price > 100 THEN 'expensive' ELSE 'cheap' END AS category，却在GROUP BY里只写category——部分数据库（如旧版MySQL）不认别名，必须写完整CASE表达式。
- 安全写法：把
CASE表达式单独定义为子查询字段，或在GROUP BY里重复写一遍完整表达式 - 注意空格和大小写：
WHEN 'A' THEN 'x'和WHEN 'a' THEN 'x'在区分大小写的数据库里是不同分组 - 聚合函数里再套
CASE更常见，比如SUM(CASE WHEN status = 'success' THEN amount ELSE 0 END)，这种不用写进GROUP BY
嵌套CASE WHEN性能差怎么办
三层以上嵌套基本等于放弃可读性和维护性，执行计划也容易变复杂。实际项目里，超过两层就该考虑替代方案。
优先级排序：先看能不能用COALESCE/NULLIF简化；再看是否适合拆成WITH临时表预计算；最后才考虑用应用层处理。
- 替代示例：
CASE WHEN a IS NOT NULL THEN a WHEN b IS NOT NULL THEN b ELSE c END→ 直接用COALESCE(a, b, c) - 涉及业务规则较多时，建一张映射表（如
status_rule），用JOIN代替长串CASE - PostgreSQL 中过度嵌套可能导致 planner 选择错误执行路径，加
/*+ HashJoin(t1 t2) */提示不一定生效，不如重构逻辑
最常被忽略的是：CASE WHEN 的求值顺序是严格从左到右，第一个满足的WHEN就终止，后面不管有没有副作用。但别依赖这个做“伪逻辑短路”，比如CASE WHEN col IS NULL THEN func() ELSE other_func() END——func()在col非空时依然可能被调用（取决于优化器）。
