嵌套超3层或分支超5个的case when必须拆分，因其在spark/hive中引发强制全分支求值、where无法下推、字段重复计算、基数估算严重偏差等执行引擎级性能硬伤。
直接结论：嵌套超过3层或分支超5个的 CASE WHEN，基本该拆了——不是“可以优化”，而是“不拆就注定慢”。
为什么嵌套 CASE WHEN 会让查询变慢？
它不是语法问题，是执行引擎层面的硬伤：
- Spark/Hive 里每个
CASE WHEN分支都会被强制解析+类型检查，哪怕第一个WHEN就已为true，后续所有分支仍要走完表达式求值流程 - 优化器无法下推
WHERE条件到数据扫描层，导致全表读取后才过滤，I/O 放大 3–8 倍 - 字段重复计算（比如
date_sub(current_date, 30)在 4 个分支里各算一次），CPU 耗时集中在ExpressionEvaluation - 基数估算偏差常达 1000 倍以上，
EXPLAIN FORMATTED显示预估行数 100，实际扫 10 万行
用 LEFT JOIN 替代 CASE WHEN 的实操要点
这是最通用、见效最快的方式，尤其适合等值映射类逻辑（如状态码转中文、用户等级打标）：
- 必须给映射表的关联字段加主键或唯一索引，否则
JOIN可能产生笛卡尔积 - 原
CASE WHEN有优先级（多个条件可能同时命中，只取第一个），映射表需加sort_order字段，并在JOIN后用ROW_NUMBER() OVER (PARTITION BY key ORDER BY sort_order)去重 - 用
LEFT JOIN+COALESCE(m.label, 'Unknown')模拟原ELSE行为；千万别用INNER JOIN，否则缺失映射的行会直接丢弃 - 如果映射表里某条记录的
label是NULL（表示禁用），要在ON条件里显式排除：ON u.type = m.type_code AND m.label IS NOT NULL
子查询中嵌套 CASE WHEN 的正确姿势
只在两类场景下允许保留 CASE WHEN，且必须严格约束写法：
- 聚合函数内部：如
SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END)—— 这是单次扫描+条件累加，不可替代 - 子查询输出列打标：把复杂判断封装成一个字段（如
risk_level），外层再按这个字段WHERE或GROUP BY；必须写ELSE，否则不匹配行变成NULL，外层筛选会漏数据 - 禁止在
WHERE或JOIN ON中直接写CASE WHEN表达式，它不会被下推，只会拖慢整个执行链 - 所有
THEN分支返回值类型必须一致，混用字符串和数字（如'high'和100）在 PostgreSQL 会报错，MySQL 可能隐式转成字符串但性能受损
容易被忽略的细节：字段类型与隐式转换
这是线上最隐蔽的性能杀手之一：
- 同一个
CASE WHEN里，不同分支返回VARCHAR(20)、VARCHAR(100)、TEXT，会导致整列被升格为TEXT，JOIN效率断崖下跌 - 分支中混用
INT和DECIMAL，触发隐式转换，不仅慢，还可能让索引失效 - 映射表的
label字段别用TEXT，统一用VARCHAR(50)并加索引；type_code用CHAR或TINYINT，别用VARCHAR(20) - 上线前务必验证：原
CASE WHEN是否含范围判断（如BETWEEN或>=）—— 映射表只支持等值，这类逻辑得保留在 SQL 层，不能硬塞进维度表
