CASE表达式不能用于JOIN的ON子句，因其属运行时求值而JOIN类型需编译期确定，会导致语法错误、优化失效及索引失效；应改用COALESCE、多LEFT JOIN或映射表等方案。
不合理。CASE表达式不能直接用在JOIN的ON子句中构造连接条件，这不是写法“不优雅”的问题，而是语法错误、执行不可控、性能灾难三重风险。
为什么ON里写CASE WHEN会报错或失效
数据库解析SQL时，JOIN类型和ON中的等值/布尔表达式是不同阶段处理的：LEFT JOIN这类关键字必须在编译期确定，而CASE WHEN是运行时求值表达式。两者根本不在同一层。
- PostgreSQL、SQL Server、MySQL 8.0+ 直接报错：
ERROR 1064或Incorrect syntax near 'CASE' - 某些旧版引擎（如部分MySQL 5.x）可能“接受”，但优化器会把
CASE简化为恒真或恒假条件，导致全表扫描或意外丢行 - 即使表面跑通，
rpwp.org_code = CASE WHEN tpwp.org_code IS NOT NULL THEN tpwp.org_code ELSE lbtpwp.org_code END这种写法会让(org_code, wp_code)复合索引完全失效
替代方案：用COALESCE预计算连接键
当目标是“优先取A字段，为空时回退到B字段”这类逻辑，COALESCE语义清晰、索引友好、各库兼容。
- 把原
CASE WHEN替换成COALESCE(tpwp.org_code, lbtpwp.org_code)，再做等值JOIN - 确保所有参与
COALESCE的字段类型一致，比如都为VARCHAR(32)，避免隐式转换阻断索引 - 如果任一字段可能为
NULL且你不希望关联上NULL值，加AND COALESCE(...) IS NOT NULL到ON中
多表动态路由：用多个LEFT JOIN + AND条件拆分
当需要根据左表字段决定关联哪张右表（比如order_type = 'goods'连products，'service'连services），不能靠CASE拼表名或字段名。
- 写两个独立
LEFT JOIN，每个ON里带互斥业务条件：ON o.ref_id = p.product_id AND o.order_type = 'goods' - 务必保证条件互斥且覆盖全集（如用
o.order_type != 'goods'补第二张表），否则会出现重复匹配或空值 - 最终字段用
CASE WHEN o.order_type = 'goods' THEN p.name ELSE s.plan_name END拼接，所有分支返回类型必须一致
更复杂场景：用映射表替代硬编码逻辑
如果CASE WHEN分支超过3–4个，或规则会频繁变更（比如状态码→关联字段映射），硬编码在SQL里已不可维护。
- 建一张小映射表
join_mapping，含type_code、target_table、join_key字段 -
LEFT JOIN join_mapping m ON o.order_type = m.type_code，再JOIN目标表时用m.join_key作为关联依据 - 加
WHERE m.join_key IS NOT NULL过滤无效映射，避免NULL引发笛卡尔积
真正难的不是写出能跑的SQL，而是让数据库能用索引、不扫全表、不生成临时表——所有把CASE WHEN塞进ON或WHERE的做法，都在悄悄绕过这些前提。
