OR条件导致JOIN变慢，因优化器难用索引且易退化为嵌套循环；推荐拆为UNION ALL、用IN替代同字段等值OR，或建临时表索引应对动态条件。
为什么OR条件会让JOIN变慢
数据库优化器在遇到 OR 时，往往无法有效利用索引（尤其是多列组合索引），容易退化为全表扫描。更麻烦的是，当 OR 出现在 ON 或 WHERE 中的 JOIN 条件里，优化器可能放弃使用连接算法（如 Hash Join、Merge Join），转而用嵌套循环（Nested Loop）暴力匹配——数据量一过十万，性能就断崖式下跌。
把OR拆成UNION ALL是最快见效的方案
这是最直接、多数场景下效果最明显的改写方式。核心逻辑是：让每个分支走独立的索引路径，再合并结果。注意必须用 UNION ALL 而非 UNION，避免去重开销。
常见错误现象：EXPLAIN 显示 type=ALL 或 rows 高得离谱；执行时 CPU 持续 100%，但磁盘 I/O 不高（说明卡在内存计算）。
实操建议：
- 每个
UNION ALL分支的WHERE或ON条件必须能命中至少一个可用索引 - 确保所有分支返回相同数量、顺序和类型的列，否则会报错
UNION types not match - 如果原查询有
ORDER BY或LIMIT，必须移到最外层，否则可能漏数据或排序失效 - 示例：把
ON a.id = b.a_id OR a.code = b.ref_code改为两个子查询分别关联a.id = b.a_id和a.code = b.ref_code，再UNION ALL
用IN替代多个等值OR更安全，但别乱用
IN 在语义上等价于多个 = 的 OR，但优化器对它的处理更成熟，尤其当右侧是常量列表时，通常能走索引范围扫描（type=range）。
使用场景有限制：
- 仅适用于「同一字段」的多个等值判断，比如
status IN ('A', 'B', 'C')，不能用于id = 1 OR name = 'x' - MySQL 8.0+ 和 PostgreSQL 对大列表（>1000 项）支持较好；旧版 MySQL 可能触发
max_allowed_packet错误 - 如果
IN右侧是子查询，且子查询返回 NULL，整个条件结果为 UNKNOWN，可能导致意外丢数据
临时表 + 索引是应对动态OR条件的兜底办法
当 OR 条件来自用户输入（如前端多选筛选）、无法静态拆分时，硬写 UNION ALL 会生成大量 SQL 变体，维护和缓存都成问题。这时可把动态条件先落库。
实操建议：
- 建一个带主键和必要索引的临时表（如
CREATE TEMPORARY TABLE tmp_filter (id INT PRIMARY KEY, type VARCHAR(10), INDEX idx_type(type))） - 把用户选中的所有过滤 ID/type 批量 INSERT 进去（用
INSERT ... VALUES (...), (...)，别单条插） - JOIN 时改用
INNER JOIN tmp_filter ON t.field = tmp_filter.field，优化器大概率选择 Index Nested Loop - 注意：PostgreSQL 中需用
CREATE TEMP TABLE；SQL Server 用#tmp；MySQL 临时表只在当前会话可见，无需手动清理
真正难处理的，是跨字段、含函数、又混着 LIKE 的 OR 条件——这种没银弹，要么加冗余字段预计算，要么接受它慢，或者换 Elasticsearch。
