如何在SQL中优化包含OR条件的JOIN关联查询性能？-SQL-PHP中文网

UNION ALL 拆分是最可靠解法，可绕过优化器对 ON 中 OR 的失效判断、避免右表全表扫描；需确保各分支走索引、复制过滤条件、列一致、用 UNION ALL 而非 UNION，并验证执行计划与语义等价。

如何在sql中优化包含or条件的join关联查询性能？

直接拆成 UNION ALL 是最可靠、见效最快的解法，能绕过优化器对 ON 中 OR 的失效判断，避免右表全表扫描。

为什么 `ON` 里写 `OR` 会让 JOIN 变慢

数据库优化器无法为 ON a.x = b.id OR a.y = b.id 这类跨字段条件生成有效索引驱动路径。它不尝试 index_merge（尤其在 JOIN 场景下基本禁用），而是直接对右表做全表扫描——哪怕 b.id 上明明有索引。
常见信号：EXPLAIN 中右表的 type 是 ALL 或 index，key 为 NULL，rows 接近右表总行数。

用 `UNION ALL` 拆分 JOIN 的实操要点

把一个含 OR 的 LEFT JOIN 拆成多个独立 LEFT JOIN，再合并：

每个分支只保留一个连接条件，确保 a.user_id = b.id 和 a.backup_user_id = b.id 各自能走 b.id 索引（或对应字段的单列索引）
若原查询是 LEFT JOIN，第二个分支必须加 WHERE a.user_id IS NULL，否则会漏掉仅匹配 backup_user_id 的行
所有公共过滤条件（如 status = 'active'、时间范围）必须复制进每个子查询的 WHERE，不能只放外层
SELECT 列列表必须完全一致：列数、顺序、类型、NULL 属性；否则报错 ERROR 1222
必须用 UNION ALL，不是 UNION——后者触发隐式排序和去重，开销更大

示例：

SELECT a.id, b.name 
FROM orders a 
LEFT JOIN users b ON a.user_id = b.id
WHERE b.status = 'active'
UNION ALL
SELECT a.id, b.name 
FROM orders a 
LEFT JOIN users b ON a.backup_user_id = b.id 
WHERE a.user_id IS NULL AND b.status = 'active';

容易被忽略的索引与逻辑陷阱

拆分后性能没提升？大概率卡在这三点：

每个分支单独执行 EXPLAIN SELECT ... WHERE，确认 type 是 ref 或 range，且 key 显示命中了你期望的索引
如果两个分支可能返回同一行（比如 user_id = 123 和 backup_user_id = 123 同时成立），UNION ALL 会产生重复数据，业务是否允许需确认
原查询含 GROUP BY、LIMIT 或 ORDER BY？这些不能简单套在外层——LIMIT 必须下推到每个子查询，ORDER BY 得放在最外层再做