Question

这两个查询之间的性能是否存在差异？

--= operator
SELECT COL1, COL2 
FROM DBO.MYTABLE 
WHERE COL1 = '1'

--like operator
SELECT COL1, COL2 
FROM DBO.MYTABLE 
WHERE COL1 LIKE '1'

在这种情况下基本上使用LIKE是错误的，但数据库引擎接受了这个。

Answer 1

结帐following post。

引用（如果它离线）：

我的下意识反应是=会更快，但我想   关于它并意识到查询优化器实际上会看到它们   同样的事情。查询针对a的查询计划   快速创建的tbFoo证实了这一点。这就是我告诉他的。

除了我稍后意识到有一个重要的警告 -   查询优化取决于语句的参数化方式。   如果它是纯粹的临时SQL并在运行时编译，那么   声明是等价的，但如果有任何计划重复使用，   通过将语句包含在存储过程中或准备它和   通过sp_executesql执行，LIKE将强加一个重要的   罚。

这是因为优化器在编译时不知道是否   LIKE运算符的参数将包含一个通配符，因此它不能   使用它的更具体的优化（包括索引选择）   可以使用=运算符。所以如果你主要传递参数没有   通配符，您将执行次优的查询计划。保持这个   在设计查询时请注意！

Answer 2

测试很容易。我使用了6000000行的表格与=和like进行了比较，而nvarchar字段未已编入索引。

使用like 'xx'

SQL Server Execution Times:
   CPU time = 6416 ms,  elapsed time = 493 ms.

使用= 'xx'

 SQL Server Execution Times:
   CPU time = 3444 ms,  elapsed time = 212 ms.

如果你喜欢使用外卡我至少认为它会更慢但是它不是

使用like 'xx%'

 SQL Server Execution Times:
   CPU time = 3168 ms,  elapsed time = 296 ms.

在前面使用外卡是另一回事。

使用like '%xx'

 SQL Server Execution Times:
   CPU time = 18017 ms,  elapsed time = 1530 ms.

所有这些测试都是在列上完成而没有索引，因此我在这里实际比较的是内部操作，它与比较相同。在执行计划中，<Intrinsic FunctionName="like">为like，<Compare CompareOp="EQ">为=。

使用like而不使用%和=的查询计划“看起来”相同，但它们不是。即使没有like，<Intrinsic FunctionName="like">仍然使用%。

SQL Server：'='和'like'运算符之间是否存在性能开销？

2 个答案: