case when不能在join中直接控制逻辑分支，但可在select或on子句中使用：select中用于生成新字段，on中仅限简单等值映射；需避免索引失效、null陷阱及复杂嵌套，优先考虑物化逻辑或查找表优化。
JOIN后直接用CASE WHEN做字段级条件计算
JOIN本身不处理逻辑分支，但可以在SELECT或ON子句里嵌套CASE WHEN，对关联后的字段做动态判断。关键不是“JOIN里写CASE”，而是“JOIN之后，在需要的位置用CASE”。
常见错误是试图在ON条件里写复杂业务逻辑却忽略索引失效风险；或者把本该在WHERE里过滤的条件塞进CASE，导致结果集膨胀。
-
CASE WHEN放在SELECT中：适合生成新字段，比如CASE WHEN orders.status = 'shipped' THEN '已发货' ELSE '待处理' END AS status_label -
CASE WHEN放在ON中：仅限简单等值映射（如ON t1.type = CASE WHEN t2.category = 'A' THEN 'X' ELSE 'Y' END），避免函数包裹被连接字段（如ON UPPER(t1.code) = t2.code会丢索引） - 别在CASE里调用子查询或聚合函数——多数数据库不支持，MySQL 8.0+、PostgreSQL允许但性能差
用CASE WHEN控制JOIN是否生效（模拟LEFT JOIN + 条件过滤）
有时需求不是“关联所有订单”，而是“只关联2023年后的订单”，这时不能只靠WHERE筛，否则会把主表没匹配的记录也滤掉。正确做法是把时间条件放进ON，再配合LEFT JOIN。
这时候CASE WHEN并不直接参与JOIN控制，但它能帮你构造更灵活的ON条件，比如按优先级匹配多个备选表：
SELECT u.name,
COALESCE(
CASE WHEN u.preferred_lang = 'zh' THEN cn.title
WHEN u.preferred_lang = 'en' THEN en.title
END,
'N/A'
) AS title
FROM users u
LEFT JOIN articles_zh cn ON u.article_id = cn.id AND u.preferred_lang = 'zh'
LEFT JOIN articles_en en ON u.article_id = en.id AND u.preferred_lang = 'en'
注意：CASE WHEN在这里没出现在ON里，而是在SELECT里做兜底选择——这是更安全、更易读的写法。强行在ON里用CASE做多路路由（如ON u.id = CASE ... END）会导致执行计划变差，且难调试。
避免CASE WHEN与NULL交互引发的意外结果
JOIN后某字段为NULL时，CASE WHEN col = 'X'永远不成立（因为NULL = 'X'结果是UNKNOWN），容易漏掉空值分支。
- 显式写
WHEN col IS NULL，不要依赖ELSE兜底所有“非X”情况 - 在ON条件中用
CASE时，如果输入可能为NULL，记得用COALESCE(col, 'default')预处理，否则匹配失败 - MySQL下
CASE表达式返回类型由第一个THEN分支决定，若首分支是字符串、后续是数字，会隐式转成字符串，可能引发数值比较异常
性能敏感场景下CASE WHEN的替代思路
当CASE分支超过5个，或涉及复杂字符串处理（如SUBSTRING、REGEXP），执行效率会明显下降，尤其在大表JOIN后计算。
这时应考虑提前物化逻辑：
- 把CASE逻辑拆成视图或CTE，让优化器有机会复用中间结果
- 用查找表（lookup table）替代硬编码CASE，例如建
status_mapping(status_code, label, priority)，然后LEFT JOIN status_mapping ON t.status = m.status_code - 在应用层做映射——如果该字段只用于展示，没必要全量在SQL里算
最常被忽略的一点：CASE WHEN本身不触发索引，但它的输入字段是否走索引，完全取决于它在WHERE/ON中的写法。别以为加了CASE就自动“智能优化”了。
