hive中50个case when常直接失败，因其导致ast节点爆炸式增长、超出jvm堆内表达式缓存容量，引发oom或编译超时；sql server中虽单用不慢，但全表扫描+udf调用+group by/join会触发执行计划退化与单线程降级。
大量 CASE WHEN 本身不直接“吃CPU”，但会显著放大执行器的表达式计算压力、编译开销和内存占用，尤其在 Hive 和 SQL Server 中容易触发隐式性能坍塌。
为什么Hive里50个CASE WHEN常直接失败
Hive 的查询编译器（特别是基于 Calcite 的 SQL 解析阶段）对单条 SELECT 中的表达式数量有硬性限制。50 个 CASE WHEN 会导致 AST（抽象语法树）节点爆炸式增长，超出 JVM 堆内表达式缓存容量，报错如 java.lang.OutOfMemoryError: GC overhead limit exceeded 或编译超时中断。
- 每个
CASE WHEN在编译期被展开为独立的条件分支树，不是“顺序判断”，而是并行构造多个逻辑路径 - 若存在嵌套（比如
CASE WHEN (CASE WHEN ...) = 'x' THEN ...），表达式会指数级膨胀，一个字段可能生成上百个中间符号引用 - Hive 2.x+ 默认禁用代码生成（
hive.optimize.cp关闭时），纯解释执行下，每行数据都要遍历全部 50 个分支做求值
SQL Server中CASE WHEN不慢，但配合某些操作就失控
CASE WHEN 单独使用几乎不增加 CPU，问题出在它常被误用于替代更高效的数据结构或触发执行计划退化。
- 在
SELECT列表里写 50 个CASE WHEN，但 WHERE 条件没过滤——意味着全表扫描后，每行都强制计算全部 50 个分支，CPU 负载线性翻 50 倍 - 如果其中任意一个分支调用了标量 UDF（用户自定义函数），整个查询将被迫降级为单线程执行，
MAXDOP失效，CPU 利用率集中在单核 100% - 当
CASE WHEN输出列参与后续GROUP BY或JOIN，优化器可能无法复用索引，转而走哈希匹配（Hash Match），此时又叠加哈希计算开销
真正该警惕的是“不可见”的资源放大
看起来只是“多写了几个判断”，实际影响发生在三个隐层：
-
编译层：Hive/Spark SQL 编译耗时陡增，可能卡在
analyze阶段；SQL Server 的query_plan_hash会因表达式增多剧烈变化，导致计划缓存失效频繁 - 执行层：每行数据要 carry 50 个中间结果字段，增大行宽，降低缓存命中率，间接拉高 L2/L3 缓存 miss 率
- 调度层：Hive on Tez/YARN 中，一个 task 的 JVM heap 常因表达式对象过多提前 OOM，触发重试与 speculative execution，集群整体吞吐下降
最易被忽略的一点：50 个 CASE WHEN 很少是业务必需的“实时计算”，多数情况本可通过维表 JOIN、预计算中间表或应用层映射来解耦——把计算从 SQL 层移出去，往往比调优单条语句更有效。
