SQL多WHERE IN条件的先后顺序是否会影响无索引场景的查询性能？

• 你的推导仅在无查询优化器、按书写顺序执行短路条件判断的极简查询逻辑下有一定合理性，但存在对复杂度计算的认知偏差，且完全不适用于主流关系型数据库。
• 主流SQL数据库中，调整WHERE条件的书写顺序不会影响查询性能，不需要刻意把小范围条件放前面。

1. 认知偏差修正 #

你对复杂度的计算存在错误：两种查询如果走无索引全表扫描，时间复杂度都是O(N)，仅存在可以忽略的常数级差异，不会出现5n和1n的量级差。
全表扫描的逻辑是逐行遍历所有N条记录，依次判断所有WHERE条件，不会遍历多次表：

• 按你假设的「按书写顺序短路判断」规则：
  • 第一种查询（id in [1,2,3,4,5] AND sub_id in [1]）：每条记录先判断id是否在5个值的列表中，满足后再判断sub_id是否为1。总开销是N次id列表匹配 + 平均5次sub_id匹配（数据量极大的前提下，符合id条件的记录只有5条）
  • 第二种查询（sub_id in [1] AND id in [1,2,3,4,5]）：每条记录先判断sub_id是否为1，满足后再判断id是否在5个值的列表中。总开销是N次sub_id等值匹配 + 平均1次id列表匹配
    两者的开销差异仅来自「匹配5个值的列表」和「等值匹配1个值」的极小差异，完全达不到5倍的差距。

2. 主流SQL数据库的实际执行逻辑 #

现在所有主流关系型数据库（MySQL、PostgreSQL、Oracle等）都自带基于成本的优化器（CBO），优化器会提前统计每个字段的数值分布、条件的筛选率，自动调整条件的判断顺序，完全不参考你写WHERE条件的先后顺序。
不管你把哪个条件写在前面，优化器都会自动把筛选率更高、判断成本更低的条件放到前面执行，你手动调整书写顺序没有任何作用。

3. 真正有效的性能优化方式 #

如果要优化这类查询的性能，调整条件顺序没有任何收益，正确的做法是给高频过滤字段加索引：

• 给sub_id加普通索引后，数据库可以直接通过索引定位到所有sub_id=1的记录，不需要全表扫描，时间复杂度直接从O(N)降到O(logN)，性能提升远大于常数级的顺序调整。
• 如果有高频的多条件过滤，也可以建联合索引进一步提升查询效率。

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