MySQL中OR条件查询与两次SELECT查询的复杂度及性能对比

首先直接给结论：这两种查询场景的耗时通常不会完全相同，多数情况下单条带OR的查询效率会略优于两次独立的查询，当然具体差异还要看MySQL版本、表数据量以及优化器的决策。

为什么耗时不同？ #

• 重复的前置开销：两次独立查询需要分别经历SQL解析、执行计划生成、优化器评估这些流程，哪怕复用了数据库连接，这些步骤的开销还是会被重复计算；而单条OR查询只需要走一次这些前置流程，节省了部分额外开销。
• 索引利用的效率差异：因为id是有索引的，MySQL优化器通常会把id = id1 OR id = id2等价转换成id IN (id1, id2)，然后通过索引执行一次范围扫描或者多次单点查找后合并结果；而两次独立查询是分别执行两次单点索引查找，虽然单次查找很快，但累积起来的小开销还是存在。
• 极端情况的例外：如果你的MySQL版本非常老旧（比如5.5之前），优化器没有做OR转IN的优化，或者id1、id2对应的行在磁盘上物理位置极度分散，两者的耗时差距可能会很小，但总体还是单条OR查询更占优。

MySQL内部如何处理OR条件？ #

MySQL对OR条件的处理逻辑主要取决于条件中涉及的字段是否有索引，分几种情况：

1. OR条件的所有字段都有可用索引（同列OR或多列OR） #

• 同列等值OR（比如你的场景）：优化器会自动将id = id1 OR id = id2转换为id IN (id1, id2)，然后利用id的索引执行Range Scan（范围扫描），或者直接进行多次单点索引查找，然后合并结果（因为id是唯一索引，不需要去重）。执行计划里的type字段通常会显示range或者ref，Extra字段可能会标注Using index（如果是覆盖索引的话，你的场景里id和name如果在索引里，就是覆盖索引，不需要回表）。
• 多列OR（比如id = 1 OR name = 'Tom'，且id、name都有索引）：MySQL会使用Index Merge Union策略：分别扫描两个字段的索引，得到各自的结果集，然后在内存中合并这两个结果集并去重，最后如果需要其他字段的话再回表获取完整数据。

2. OR条件中存在无索引的字段 #

如果OR条件里有某个字段没有索引（比如id = 1 OR age = 20，age无索引），MySQL优化器会认为全表扫描的成本更低，此时会触发Full Table Scan，逐行检查是否满足OR条件。

3. 唯一索引的OR特殊处理 #

当OR条件是针对唯一索引的等值匹配时，优化器会直接将每个等值条件视为独立的单点查询，快速定位到对应的行，然后合并结果，这个过程的效率非常高，因为唯一索引的查找是O(1)级别的。

如果你想确认具体的执行逻辑，可以用EXPLAIN命令查看执行计划，比如：

EXPLAIN SELECT id, name FROM Customers WHERE id = id1 OR id = id2;

对比两次独立查询的EXPLAIN结果，就能清楚看到优化器的决策差异。

内容的提问来源于stack exchange，提问作者tezz