SQL Server 2017(RDS)中多模糊LIKE查询为何快于单组合LIKE？

嘿，这个反直觉的性能结果确实有意思，咱们来一步步拆解为什么多模糊LIKE的查询2反而比单LIKE的查询1更快：

1. 执行计划的核心差异 #

SQL Server的查询优化器不会只看条件数量，而是会根据条件逻辑和数据分布生成最优执行计划。哪怕两个查询返回结果一致，执行路径可能天差地别：

• 如果查询1的单LIKE是前后都带通配符（比如WHERE v LIKE '%abc%'），这种模式完全无法利用索引的Seek操作，只能走全表扫描或者索引扫描；而查询2的多个LIKE条件，可能被优化器重写成了能部分利用索引的形式——比如如果其中某个LIKE是前缀匹配（'abc%'），优化器会先通过索引Seek过滤出这部分数据，再用其他条件二次筛选，整体IO量会少很多。
• 另外，查询2的多条件组合可能让优化器选择了覆盖索引：如果你的索引包含了查询需要的所有列，就不用回表查询主键对应的行数据，这会大幅减少逻辑读的次数。

2. 统计信息的准确性偏差 #

Amazon RDS上的统计信息如果过时，会误导查询优化器做出错误的计划选择：

• 假设查询1的单LIKE条件，优化器根据旧统计信息预估会返回大量数据，于是选择了全表扫描；但实际数据中匹配的行数很少，全表扫描反而比索引扫描更慢。
• 而查询2的多条件组合，优化器对其返回行数的预估更准确（多个条件的过滤效果叠加，预估行数更接近实际），所以选择了更高效的索引操作。
  你可以尝试执行UPDATE STATISTICS Vehicles;更新统计信息后再测试性能，看差异是否缩小。

3. 查询重写与优化器的特殊处理 #

SQL Server的优化器会对多OR/AND的LIKE条件做隐性重写：

• 比如如果查询2的多个LIKE逻辑等价于查询1（比如查询1是LIKE '%abcdef%'，查询2是LIKE '%abc%' AND LIKE '%def%'），优化器可能会把查询2的条件转换成更高效的内部表达式，而单LIKE的条件反而没有这种优化空间。
• 另外，RDS上的SQL Server可能针对多条件查询有特定的优化逻辑（比如并行执行的触发条件），让查询2能利用更多CPU资源完成计算。

4. 数据分布与过滤效率的隐性差异 #

虽然两个查询返回结果相同，但实际执行时的过滤顺序可能不同：

• 查询2的多个LIKE条件可能先过滤掉了大部分不匹配的数据，后续处理的行数远少于查询1的单条件过滤。比如查询1的单LIKE需要扫描所有行判断是否匹配，而查询2的第一个LIKE就过滤掉了80%的行，剩下的20%再用第二个LIKE判断，整体耗时更短。

排查建议 #

想要彻底搞清楚原因，你可以做这几件事：

• 对比两个查询的实际执行计划：重点看索引使用情况（是Index Seek还是Index Scan/Table Scan）、逻辑读/物理读的数值、是否有Key Lookup（回表操作）。
• 检查查询的参数化状态：如果是带参数的查询，是否存在参数嗅探导致的计划偏差？可以尝试强制重新编译查询（OPTION (RECOMPILE)）后再测试。
• 查看RDS实例的性能指标：比如CPU、IO使用率，确认查询1是否因为IO瓶颈导致变慢。

内容的提问来源于stack exchange，提问作者Mason G. Zhwiti