CASE WHEN 非万能，错用位置、漏ELSE、混用聚合函数致结果偏差；WHERE中不可直接用其过滤；需区分简单CASE与搜索CASE的NULL处理；GROUP BY中嵌套须保持逻辑原子性。
CASE WHEN 不是万能开关，但写错位置、漏写 ELSE 或混用聚合函数时，结果会完全偏离预期。
WHERE 子句里不能直接用 CASE WHEN 做条件过滤
很多人想在 WHERE 里写 CASE WHEN status = 'A' THEN id > 100 ELSE id ，这是语法错误——<code>WHERE 只接受布尔表达式，不接受 CASE 返回的值。真正能用的地方是 SELECT、ORDER BY、HAVING（配合聚合），以及某些支持表达式的位置（如 INSERT ... VALUES）。
- ✅ 正确：在
SELECT中做字段映射，比如把状态码转成中文：CASE WHEN status = 'active' THEN '启用' ELSE '停用' END AS status_text - ✅ 正确：在
ORDER BY中按业务优先级排序：ORDER BY CASE WHEN priority = 'high' THEN 1 WHEN priority = 'low' THEN 3 ELSE 2 END - ❌ 错误：把整个
CASE表达式当布尔条件塞进WHERE，MySQL 会报ERROR 1064
简单 CASE 和搜索 CASE 的语法差异容易导致逻辑错位
简单 CASE（CASE expr WHEN value THEN ...）只做等值判断；搜索 CASE（CASE WHEN condition THEN ...）支持任意布尔表达式。混用或误选会导致条件永远不匹配。
- 用简单
CASE判断范围？不行：CASE score WHEN > 90 THEN 'A'是语法错误 - 需要用搜索
CASE：CASE WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' ELSE 'C' END - 注意 NULL 处理：简单
CASE中expr为NULL时，所有WHEN value都不匹配，直接走ELSE；而搜索CASE中WHEN column IS NULL才能捕获空值
在 GROUP BY 或聚合中嵌套 CASE WHEN 必须保持逻辑原子性
常见需求是“按年龄段分组统计”，但若在 GROUP BY 中写 CASE WHEN age ，必须确保 <code>SELECT 列表里的对应字段也用完全一致的 CASE 表达式，否则 MySQL 8.0+ 严格模式下会报 ERROR 1055。
- ✅ 安全写法：
SELECT CASE WHEN age < 18 THEN 'minor' ELSE 'adult' END AS age_group, COUNT(*) FROM users GROUP BY CASE WHEN age < 18 THEN 'minor' ELSE 'adult' END
- ⚠️ 危险写法：在
SELECT里用一个CASE，GROUP BY里用另一个（哪怕只是多了一个空格），就可能触发报错或隐式转换 - 性能提示：这类表达式无法使用索引，大数据量时考虑提前计算并建虚拟列（
GENERATED COLUMN）加索引
没有 ELSE 时默认返回 NULL，线上统计容易漏数据
几乎所有出问题的 CASE WHEN 场景，都源于漏写 ELSE。比如按订单状态分类，只写了 WHEN 'paid' 和 WHEN 'shipped'，但实际还有 'cancelled'、'pending' 等状态——这些行在结果中对应字段全为 NULL，而 COUNT(*) 仍会计数，COUNT(column) 却会忽略它们，造成统计口径不一致。
- 强制习惯：每个
CASE后都补上ELSE 'unknown'或ELSE 0，哪怕当前业务认为“不可能有其他值” - 调试技巧：临时把
ELSE改成ELSE CONCAT('unhandled:', status)，跑一遍看有没有意外字符串冒出来 - 特别注意：在
UPDATE语句中漏ELSE，会导致目标字段被设为NULL，且不会报错
最常被忽略的是 CASE 表达式的求值顺序：从上到下、一旦匹配就退出。这意味着条件排列要严格按优先级，比如先判 status = 'cancelled'，再判 status = 'paid'，否则已取消的订单可能被错误归入“已支付”组。
