SQL Server中T-SQL查询性能：不同WHERE条件顺序的执行速度对比

两条查询的执行速度完全相同，不存在谁快谁慢的差异。

为什么WHERE条件的书写顺序不影响性能 #

SQL是声明式查询语言，你在语句中描述的是「需要返回什么结果」，而非「数据库要按什么步骤做操作」。
SQL Server的基于成本的查询优化器在处理即席查询时，会在解析阶段把所有AND连接的过滤条件做逻辑等价化简、重排：A AND B和B AND A在逻辑上是完全等价的命题，原始语句里的条件先后顺序会被直接丢弃，根本不会参与后续的执行计划决策。
这和应用层代码的if短路逻辑有本质区别：应用层写if(id条件 && name条件)会因为短路减少无意义的判断，但数据库引擎绝不会照搬你写的文本顺序来安排执行步骤。

结合当前表结构的实际执行路径 #

当前Product表的结构特征是：

• id列是聚集索引键
• name列没有建立任何索引
  优化器在评估所有可行执行路径的成本时，会直接排除高成本选项：如果优先匹配name = 'ABC'的条件，因为没有索引支持，必须对整个聚集索引做全扫描逐行校验，成本和表的数据量正相关，开销极高。
  而通过id列的聚集索引做等值查找，只需要几次索引页跳转就能定位到id = '12345'对应的记录，成本极低。
  因此无论你怎么调整WHERE子句里两个条件的先后顺序，最终生成的执行计划是完全一致的：
• 第一步：在聚集索引上通过Seek操作定位所有满足id = '12345'的记录
• 第二步：对定位到的这些行数极少的记录，做残余谓词校验，判断该行的name值是否等于'ABC'
• 第三步：返回同时满足两个条件的结果行
  两条查询的IO开销、CPU计算量没有任何区别，自然执行速度完全一致。另外两个查询都加了相同的(nolock)表提示，锁行为、数据读取范围完全相同，也不会带来速度差异。

常见误区澄清 #

很多开发者写查询时会刻意把带索引的条件放在WHERE子句的最前面，觉得这样能引导数据库先走索引、减少扫描量。实际上只要表的统计信息准确，SQL Server的优化器永远会自动选择成本最低的执行路径，根本不会因为条件的书写顺序改变决策。刻意调整条件顺序对性能没有任何增益，反而会增加语句的维护成本。

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