直接结论：只要CASE WHEN出现在JOIN ON或WHERE条件里，基本就该重写——它不会下推，只会拖慢全链路；应改用映射表+LEFT JOIN替代ON中的动态逻辑，并确保字段类型一致、显式处理NULL与ELSE。
CASE WHEN 和 JOIN 混用时，性能崩坏往往不是因为写法“错”，而是执行引擎被迫做大量无用计算。直接结论：**只要 CASE WHEN 出现在 JOIN ON 或 WHERE 条件里，基本就该重写——它不会下推，只会拖慢全链路**。
为什么不能在 JOIN ON 里写 CASE WHEN？
数据库优化器（尤其是 Spark、Hive、PostgreSQL）对 ON 中的表达式极其保守：CASE WHEN a.status = 'A' THEN b.id ELSE b.alt_id END = c.ref_id 这类逻辑会导致：
• 无法利用 b.id 或 b.alt_id 上的索引，强制走全表扫描
• JOIN 前无法过滤，两表先笛卡尔积再计算，内存爆涨
• 执行计划里常出现 Filter: (CASE ...) 在 Nested Loop 外层，说明关联已完成才开始判断
• MySQL 8.0+ 和 PostgreSQL 14 会尝试物化中间结果，但字段类型不一致（比如混用 INT 和 VARCHAR）会触发隐式转换，进一步阻断索引使用
用映射表 + LEFT JOIN 替代 ON 中的 CASE WHEN
这是最稳妥、见效最快的重构方式，尤其适合“状态码→业务标签”“ID类型→主键字段”这类等值映射：
- 把原
CASE WHEN的分支整理成一张小映射表（如id_mapping），含字段：type_code（输入）、target_col（要 JOIN 的字段名或值）、sort_order（保留优先级） -
LEFT JOIN id_mapping m ON t1.type = m.type_code，然后ON t2.id = m.target_col—— 把动态选择字段的行为，变成静态字段匹配 - 务必加
WHERE m.target_col IS NOT NULL或ON ... AND m.target_col IS NOT NULL，否则NULL值会让JOIN变成无效连接 - 如果原逻辑有
ELSE t1.fallback_id，用COALESCE(t2.id, t1.fallback_id)拉平，别在ON里再套一层CASE
WHERE 条件里有 CASE WHEN 怎么办？
绝对禁止写成 WHERE (CASE WHEN t.status = 'paid' THEN t.amount ELSE 0 END) > 100。这种写法等于告诉数据库：“先算完所有行的 CASE，再过滤”。正确做法是拆条件：
- 把每个
WHEN分支单独拎出来，用UNION ALL拼接（前提是各分支互斥且能独立走索引） - 更推荐：提前在子查询或 CTE 里计算出新列，比如
SELECT *, CASE WHEN status = 'paid' THEN amount ELSE 0 END AS paid_amount FROM orders，外层再WHERE paid_amount > 100—— 这样优化器有机会把过滤下推到扫描阶段 - 注意：子查询里必须写
ELSE，否则NULL值在WHERE中被直接丢弃，结果集变少
字段类型不一致是隐形炸弹
同一个 CASE WHEN 里，不同分支返回 VARCHAR(10)、VARCHAR(255)、TEXT，整列会被升格为 TEXT；混用 INT 和 DECIMAL(10,2) 会触发隐式转换。后果很直接：
-
JOIN字段变成TEXT后，哈希连接失效，退化成嵌套循环 - 索引失效：即使
status列有索引，CASE WHEN status IN ('a','b') THEN 1 ELSE 0 END = 1也无法走索引 - Spark SQL 中，类型升格还会导致 shuffle 数据量暴增，任务卡在
Exchange阶段
真正麻烦的从来不是语法怎么写，而是你没意识到：数据库看到的不是你的业务逻辑，它只认表达式求值路径和类型契约。
