简单CASE仅支持等值判断，搜索CASE支持完整布尔表达式；日常多条件分支必须用搜索CASE，简单CASE仅适用于字段枚举映射。
MySQL中CASE WHEN的两种写法区别在哪
直接说结论：简单CASE（CASE column WHEN value THEN ...）只支持等值判断，不能用>、IS NULL或函数；搜索CASE（CASE WHEN condition THEN ...）才支持完整布尔表达式，日常90%的多条件分支都得用它。
容易踩的坑是误以为CASE column WHEN expr1 THEN ... WHEN expr2 THEN ...能写column > 10——这会报错，因为expr1必须是字面值或列名，不能是表达式。
实操建议：
- 所有含比较运算符、函数调用、NULL判断的逻辑，一律用搜索CASE：
CASE WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' ELSE 'C' END - 简单CASE仅用于“字段值枚举映射”，比如
CASE status WHEN 1 THEN 'active' WHEN 0 THEN 'inactive' END - 两者都必须有
ELSE（或省略，此时默认为NULL），否则遇到不匹配条件会返回NULL，常被误认为“没生效”
在SELECT、UPDATE、ORDER BY里怎么安全用CASE WHEN
它不是流程控制语句，而是表达式，所以能在任何需要值的地方出现——但不同上下文对返回类型和NULL处理敏感。
常见错误现象：在ORDER BY里用CASE后排序乱序，或UPDATE里赋值变成NULL却没报错。
实操建议：
-
SELECT中可直接用，但注意各THEN分支返回类型要一致，否则MySQL隐式转换可能出错（如混合字符串和数字，结果全转成浮点数） -
UPDATE中作为SET右侧值时，确保ELSE覆盖所有情况，否则更新字段变NULL（尤其WHERE条件漏掉某些行时） -
ORDER BY里用CASE实现自定义排序顺序（如把'urgent'排最前），但别在THEN里返回表达式，只返回常量或确定值，避免排序不稳定
嵌套CASE WHEN和性能影响怎么权衡
可以嵌套，但三层以上就该警惕：可读性断崖下跌，且MySQL无法对嵌套CASE做有效优化，执行计划里常显示Using filesort或Using temporary。
真实场景中，嵌套往往暴露了设计问题——比如用CASE模拟状态机流转，其实该拆成独立状态字段或用外键关联状态表。
实操建议：
- 单层CASE解决不了的逻辑，先检查是否能用
JOIN+ 状态映射表替代（例如把几十种订单状态码映射到中文名，用表比硬编码CASE更易维护） - 必须嵌套时，把高频分支放在前面（MySQL按顺序求值，不满足WHEN就跳过后续）
- 在WHERE子句里避免用CASE做过滤条件（如
WHERE CASE WHEN x>0 THEN y ELSE z END = 1），这会让索引失效，改用布尔逻辑重写：WHERE (x>0 AND y=1) OR (x
NULL值在CASE WHEN里的行为陷阱
CASE表达式本身不特殊处理NULL：WHEN后的条件如果是col = NULL，永远为UNKNOWN，不会命中；而col IS NULL才是正确写法。
更隐蔽的是：如果所有WHEN条件都不满足，且没写ELSE，整个CASE返回NULL——这个NULL可能被上层函数（如COALESCE、SUM）静默吞掉，导致结果不符合预期。
实操建议：
- 显式处理NULL分支：
CASE WHEN col IS NULL THEN 'unknown' WHEN col = 'a' THEN 'A' ELSE 'other' END - 在聚合场景下，慎用CASE返回NULL再交给
SUM()或COUNT()——SUM(CASE WHEN ... THEN 1 ELSE NULL END)会忽略NULL，等价于COUNT符合条件的行；但COUNT(CASE WHEN ... THEN 1 ELSE NULL END)也只计非NULL，效果一样；真要统计全部行，用COUNT(*)更直白 - 调试时加
ELSE CONCAT('UNHANDLED:', col)临时捕获漏掉的值，上线前删掉
真正难的不是语法，是想清楚“这个分支逻辑到底属于数据清洗层，还是应该推给应用层处理”。CASE WHEN越复杂，越要问一句：我是不是在SQL里写了不该写的业务规则？
