CASE WHEN是表达式而非流程控制语句，必须同类型返回值、显式ELSE、慎用嵌套；简单CASE仅支持等值匹配，搜索CASE支持任意布尔条件；避免WHERE/GROUP BY中滥用导致索引失效。
直接用 CASE WHEN 就能实现复杂条件逻辑，关键不在“能不能”，而在“怎么写才不翻车”——它不是流程控制语句，而是表达式，所有分支必须返回同类型值，且顺序决定结果。
区分简单 CASE 和搜索 CASE 的使用场景
简单 CASE status WHEN 1 THEN '启用' WHEN 0 THEN '禁用' END 只做等值匹配，底层是逐个比对字段值，不能写 WHEN status > 0 或 WHEN status IS NULL，一写就报错。搜索 CASE WHEN age >= 18 THEN '成人' WHEN age BETWEEN 6 AND 17 THEN '少年' END 才支持任意布尔条件，日常 90% 的业务判断（多字段组合、范围、NULL 检查）都得靠它。
- 状态码映射、枚举转义优先用简单 CASE，语义清晰、性能略优
- 涉及
>、BETWEEN、IS NULL、AND/OR组合的，必须用搜索 CASE - 简单 CASE 内部不支持函数调用，比如
CASE UPPER(status) WHEN 'ACTIVE'...会语法错误
所有 THEN 分支的返回值类型必须严格一致
MySQL 不会报类型冲突错误，但会静默转成最高优先级类型——常见后果是数字被转成字符串后无法参与 SUM 或排序，或长度被截断。比如 CASE WHEN flag = 1 THEN 100 ELSE 'N/A' END 整列变成 VARCHAR，后续 AVG() 直接返回 0。
- 统一用字符串：
THEN '100' ELSE 'N/A' - 统一用数字：
THEN 100 ELSE -1（注意 -1 要和业务含义兼容） - 涉及金额/计数，宁可补默认数值（如 0），别混用字符串
-
ELSE必须显式写，不写默认为NULL，聚合时会被忽略，WHERE 中可能漏行
嵌套 CASE 要控制深度，优先抽离判断依据
三层以上嵌套的 CASE WHEN ... THEN CASE WHEN ... END END 很难维护，也容易让优化器生成低效执行计划。真实项目里更稳妥的做法是先用子查询或 JOIN 计算出一个中间状态码，再单层 CASE 映射。
- 避免：
CASE WHEN region = '华东' THEN CASE WHEN level = 'VIP' THEN ... END END - 推荐：
SELECT ..., CASE status_code WHEN 1 THEN '华东VIP' WHEN 2 THEN '华北普通' END FROM (SELECT *, CASE WHEN region = '华东' AND level = 'VIP' THEN 1 ... END AS status_code FROM orders) t - 嵌套时注意括号配对，
IF()和CASE混用极易漏END或多套括号 - MySQL 5.7+ 对嵌套超 5 层的
CASE可能拒绝生成有效执行计划
别在 WHERE 或 GROUP BY 里滥用 CASE 表达式
WHERE CASE WHEN status = 'active' THEN 1 ELSE 0 END = 1 看似能跑，实则让索引完全失效，等价于全表扫描。同样，GROUP BY vip_flag（其中 vip_flag 是 SELECT 里的 CASE 别名）在多数 MySQL 版本中会报错，必须写完整表达式。
- 过滤逻辑一律下推到 WHERE 原生条件：
WHERE status = 'active'，而不是绕一圈CASE -
GROUP BY和ORDER BY中若需按条件分组，必须重复写整个CASE表达式，不能用别名 - 想实现“按地区优先级排序”，写
ORDER BY CASE WHEN region = '华东' THEN 0 ELSE 1 END, created_at DESC，别试图先算再引用 -
HAVING中可用CASE，但要注意它作用于分组后，和 WHERE 语义完全不同
最常被忽略的一点：CASE 表达式本身不改变数据物理存储，它只是查询时的“视图层转换”。如果你需要基于条件结果建索引或加约束，得用生成列（GENERATED COLUMN）配合 STORED 属性，而不是依赖 SELECT 里的 CASE。
