不能在 join 的 on 子句中直接使用 case when，因 sql 标准禁止其破坏等值连接语义、阻碍优化器估算基数与索引选择；应改用子查询预计算关联键或多个 left join 分流，并将右表过滤条件移入 on。
不能在 JOIN 的 ON 子句里直接写 CASE WHEN 作为连接表达式——所有主流数据库（MySQL 8.0+、PostgreSQL、SQL Server）都会报错或拒绝执行。
ON 子句里写 CASE WHEN 为什么会报错？
SQL 标准禁止把 CASE WHEN 当作连接条件的一部分，因为这会让优化器无法预估关联基数、无法选择索引，甚至破坏等值连接的语义基础。比如下面这种写法必然失败：
LEFT JOIN orders o ON o.id = CASE WHEN u.type = 'vip' THEN u.vip_order_id ELSE u.normal_order_id END
错误现象通常是：syntax error near CASE 或 invalid use of CASE in ON clause。这不是数据库版本问题，而是语法层面不被允许。
用子查询预计算动态关联键
这是最通用、兼容性最好的解法：先把需要动态决定的关联字段用 CASE WHEN 算出来，再基于这个结果做标准等值 JOIN。
-
CASE WHEN必须返回统一类型（如全为INT或全为VARCHAR），否则关联可能静默失败 - 每个分支都要有明确
ELSE NULL，避免意外匹配到非目标记录 - 子查询必须起别名，且外层
ON中引用的列要来自该别名，否则旧版 MySQL 会报Unknown column in ON clause
示例：
SELECT o.*, u.name
FROM orders o
JOIN (
SELECT id,
CASE
WHEN order_type = 'direct' THEN user_id
WHEN order_type = 'agent' THEN agent_id
ELSE NULL
END AS join_key
FROM orders
) o2 ON o.id = o2.id
JOIN users u ON u.id = o2.join_key;
用多个 LEFT JOIN + 条件过滤替代
当“动态逻辑”本质是“按类型分流关联不同表”，就不要硬塞进一个 JOIN，而是拆成多个 LEFT JOIN，并在每个的 ON 中带上业务判断条件。
- 每个
ON必须同时包含关联字段和类型条件，例如ON u.id = o1.user_id AND u.type = 'vip'；只写u.id = o1.user_id会导致笛卡尔积 - 类型条件之间要互斥且覆盖全集，否则会出现空值或重复匹配
- 右表字段不一致时，在
SELECT层用CASE WHEN对齐输出，所有THEN分支返回值类型必须一致
示例：
SELECT u.*,
CASE
WHEN u.type = 'vip' THEN o1.amount
ELSE o2.amount
END AS order_amount
FROM users u
LEFT JOIN vip_orders o1 ON u.id = o1.user_id AND u.type = 'vip'
LEFT JOIN normal_orders o2 ON u.id = o2.user_id AND u.type != 'vip';
WHERE 里引用右表字段会让 LEFT JOIN 失效
这是最容易忽略的陷阱：一旦在 WHERE 中写了类似 o.status = 'paid' 的条件，哪怕 JOIN 是 LEFT，效果也等同于 INNER JOIN——所有右表为 NULL 的左表记录都会被过滤掉。
正确做法是把右表的筛选条件全部移到对应 ON 子句中：
- 错：
LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid' - 对：
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'
记住：ON 控制“怎么连”，WHERE 控制“连完怎么筛”。只要左表需要全量保留，右表的所有过滤逻辑就必须进 ON。
