CASE WHEN在WHERE中不能直接作布尔条件，须返回标量值后与比较符连用；SELECT中需注意类型对齐与NULL默认值。
WHERE 里不能直接写 CASE WHEN？先看执行顺序
sql 的执行顺序决定了 case when 在 where 中不能“直接当条件用”——它不是布尔表达式，而是值生成器。你写 where case when x > 1 then 1 else 0 end = 1 是合法的，但写 where case when x > 1 then true else false end 在多数数据库（如 mysql、postgresql）会报错或隐式转义，行为不可靠。
常见错误现象：ERROR: syntax error at or near "CASE"（PostgreSQL）、Unknown column 'CASE' in 'where clause'（MySQL 旧版本）。
- 真正能用在
WHERE的是「返回标量值」的CASE WHEN，再跟比较符连用 - 如果逻辑复杂、分支多，优先考虑拆成多个
OR/AND组合，而不是硬套CASE - MySQL 5.7+ 支持布尔上下文中的
CASE，但 PostgreSQL 要求显式比较，兼容性差
SELECT 中用 CASE WHEN 做动态列，注意 NULL 和类型对齐
CASE WHEN 在 SELECT 里最常用，但它不保证所有分支返回同类型，容易引发隐式转换或截断。
使用场景：按订单金额分档打标签（'small' / 'medium' / 'large'），同时还要显示原始金额。
- 所有
THEN分支和ELSE分支必须返回兼容类型；混用字符串和数字（比如THEN 1和ELSE 'N/A'）会让整列变成TEXT或触发警告 - 没写
ELSE且条件全不匹配时，默认返回NULL，不是空字符串——这点常被忽略，导致前端展示异常 - PostgreSQL 对类型推导更严格，MySQL 可能自动转成
VARCHAR(1)导致内容被截断
示例：
SELECT order_id,
CASE
WHEN amount < 100 THEN 'small'
WHEN amount < 1000 THEN 'medium'
ELSE 'large'
END AS size_label
FROM orders;
UPDATE 语句中嵌套 CASE WHEN，避免全表扫描陷阱
用 CASE WHEN 在 UPDATE 里实现不同条件更新不同字段值，写法简洁，但容易误伤性能。
常见错误现象：执行变慢、锁住整张表、主从延迟飙升。
- 数据库无法对
CASE WHEN内部条件做索引下推，即使你写了WHERE id IN (…)，仍可能因CASE表达式涉及函数或计算，导致优化器放弃索引 - 别在
SET子句里对同一字段写多个CASE（比如SET status = CASE…, score = CASE…），看起来清晰，但每多一个CASE就多一次全行计算 - 如果分支逻辑可拆，优先用多个带
WHERE的单字段UPDATE，尤其在高并发写场景下更可控
GROUP BY + CASE WHEN 分组聚合，小心 NULL 分组和边界遗漏
用 CASE WHEN 动态构造分组维度（比如按年龄段、价格区间聚合），是最容易出数据偏差的地方。
使用场景：统计每个价格区间的订单数，区间定义为 [0,50), [50,200), [200,+∞)。
- 漏写
ELSE会导致NULL单独成一组，而你可能以为它被归进“其他”，实际查不到这条记录 - 区间边界用
还是 <code> 必须统一，否则 <code>50会同时不属于[0,50)也不属于[50,200)，直接消失 - MySQL 8.0+ 允许在
GROUP BY里直接写CASE表达式，但低版本要求该表达式必须出现在SELECT列表中，否则报错Expression #1 of SELECT list is not in GROUP BY clause
示例：
SELECT
CASE
WHEN price < 50 THEN 'low'
WHEN price < 200 THEN 'mid'
ELSE 'high'
END AS price_level,
COUNT(*) AS cnt
FROM products
GROUP BY price_level;
最麻烦的其实是嵌套三层以上的 CASE WHEN：逻辑难读、调试困难、数据库优化器彻底放弃推导。与其堆 CASE，不如提前在应用层或用 CTE 拆解中间状态。
