SQL中WHERE或ON子句不能直接用CASE WHEN返回布尔表达式，需改用UNION ALL、分开JOIN+COALESCE、LATERAL（PostgreSQL）或重构为多张关联表等方案。
WHERE子句中用CASE WHEN拼接连接条件行不通
直接在ON或WHERE里写CASE WHEN a.type = 'user' THEN a.id = b.user_id ELSE a.id = b.order_id END会报语法错误——SQL标准不支持把布尔表达式当值返回，CASE只能返回具体值（如数字、字符串），不能返回逻辑判断本身。
真正可行的思路是把“动态”拆成多个确定的连接路径，再用UNION ALL合并结果，或者改用OR组合等价条件（但要注意索引失效风险）。
用OR组合多组ON条件要小心索引失效
比如想根据source_type字段决定连users还是products表，可以这样写：
SELECT t.*, u.name AS ref_name FROM tickets t LEFT JOIN users u ON (t.source_type = 'user' AND t.source_id = u.id) LEFT JOIN products p ON (t.source_type = 'product' AND t.source_id = p.id)
但更常见的写法是单次LEFT JOIN配合OR：
LEFT JOIN ref_table r ON (t.source_type = 'user' AND t.source_id = r.id) OR (t.source_type = 'product' AND t.source_id = r.id)
这种写法会让大多数数据库（MySQL 5.7/8.0、PostgreSQL）放弃使用r.id上的索引，全表扫描。如果ref_table很大，性能会断崖下跌。
- 优先选分开JOIN + COALESCE：用两个LEFT JOIN分别连不同表，再用
COALESCE(u.name, p.name)取非空值 - 若必须用单表模拟多态关联，给
(source_type, source_id)建联合索引能缓解部分压力 - PostgreSQL可用
INCLUDE索引把name字段带上，减少回表
PostgreSQL中用LATERAL实现运行时选择连接目标
当连接逻辑更复杂（比如要查最近一笔订单、或按规则调用函数获取ID），LATERAL比硬写OR更清晰且可优化：
SELECT t.*, r.name FROM tickets t LEFT JOIN LATERAL ( SELECT name FROM users WHERE id = t.source_id AND t.source_type = 'user' UNION ALL SELECT name FROM products WHERE id = t.source_id AND t.source_type = 'product' LIMIT 1 ) r ON true
LATERAL子查询能引用左侧表字段，执行时按每行t动态生成查询，优化器有机会对每个分支单独走索引。但注意UNION ALL里每个子句仍需独立满足索引条件，否则还是慢。
- MySQL不支持
LATERAL（8.0.14+才引入，且功能受限），别直接照搬 - SQL Server对应的是
APPLY，语法和语义接近 - 哪怕用了
LATERAL，也得确保source_id在各目标表上都有索引，否则等于白写
真正需要“动态”的时候，往往该重构表结构
频繁出现source_type/source_id这种设计，通常说明业务存在多态关联，而SQL不是为这种场景设计的。硬撑容易导致查询越来越难维护、索引越来越难建、权限越来越难控。
更可持续的做法是：
- 拆成
tickets_users和tickets_products两张关联表，各自有明确外键和索引 - 用视图封装常用查询，对外保持接口不变
- 如果必须保留单字段，至少加CHECK约束：
CHECK ((source_type = 'user' AND source_id IN (SELECT id FROM users)) OR (source_type = 'product' AND source_id IN (SELECT id FROM products)))
动态连接看着灵活，实际是把数据建模的缺陷拖到查询层来补——补得越用力，后续越难收场。
