ON中用OR会导致笛卡尔积膨胀、索引失效及重复记录；应改用UNION ALL拆分JOIN或LEFT JOIN+COALESCE组合，并严格区分ON（关联逻辑）与WHERE（过滤逻辑）。
OR条件直接写在ON子句里会出什么问题
很多初学者会把 OR 直接塞进 JOIN ... ON，比如：
SELECT * FROM orders o JOIN customers c ON c.id = o.customer_id OR c.email = o.email_hint
这看起来逻辑通顺，但实际执行时容易触发全表扫描、索引失效，甚至返回意外的笛卡尔积结果。因为优化器很难为含 OR 的 ON 条件生成高效执行计划，尤其当两边字段来自不同索引或类型不一致时（比如 INT 和 VARCHAR 比较）。
用UNION ALL替代ON里的OR更可控
把多个独立匹配路径拆开，各自走索引，再合并结果，通常更可靠：
- 每个
SELECT子句单独写一个JOIN，ON里只用=或范围条件 - 确保所有子查询返回相同数量和类型的列，必要时用
NULL占位 - 用
UNION ALL而非UNION，避免隐式去重开销 - 如果业务允许重复（比如同一客户既匹配ID又匹配邮箱），就保留重复；否则在外层加
DISTINCT或用ROW_NUMBER()去重
示例：
SELECT o.*, c.name, 'by_id' AS match_type FROM orders o JOIN customers c ON c.id = o.customer_id UNION ALL SELECT o.*, c.name, 'by_email' FROM orders o JOIN customers c ON c.email = o.email_hint AND o.customer_id IS NULL
注意第二部分加了 o.customer_id IS NULL 防止重复匹配——这是容易漏掉的业务约束。
LEFT JOIN + COALESCE组合适合“优先匹配某字段”场景
当你要按优先级尝试多个关联字段（比如先试 user_id，没找到再试 username），LEFT JOIN 比 INNER JOIN 更安全：
- 用两个
LEFT JOIN分别关联，别名区分开（如c1,c2） - 用
COALESCE(c1.name, c2.name)取第一个非空值 - 关键点：第二个
LEFT JOIN的ON条件里要排除第一个已匹配的记录，否则结果行数会翻倍
例如：
SELECT o.*, COALESCE(c1.name, c2.name) AS customer_name FROM orders o LEFT JOIN customers c1 ON c1.id = o.customer_id LEFT JOIN customers c2 ON c2.username = o.username_hint AND c1.id IS NULL
这里 c1.id IS NULL 是必须的，否则 c2 会对每条订单都尝试匹配，不管 c1 是否成功。
用EXISTS + OR子查询替代JOIN时的性能陷阱
如果只是判断“是否存在满足任一条件的关联记录”，不用返回关联表字段，EXISTS 往往比 JOIN 更轻量：
-
EXISTS只关心是否存在，找到一个就短路退出，不构建中间结果集 - 子查询里写
OR没有JOIN那么重的代价，尤其配合索引字段时 - 但要注意：子查询里不能引用外部查询的非关联字段（除非是相关子查询），且
OR两侧最好都有索引支持
例如：
SELECT * FROM orders o WHERE EXISTS ( SELECT 1 FROM customers c WHERE c.id = o.customer_id OR c.email = o.email_hint )
这种写法在 orders 表很大、但匹配率很低时，比 JOIN 更省内存和IO。
真正难的不是写出带 OR 的SQL，而是判断该用哪种结构——取决于你到底要数据、要存在性、还是要控制匹配优先级。索引是否覆盖、NULL值怎么处理、重复要不要去，这些细节一旦忽略，结果可能对得离谱，但性能崩得更快。
