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

这两个查询在性能上有差异吗？SQL Server：'='和'like'运算符之间是否存在性能开销？

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

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

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

来源

2011-11-17 jrara

结帐following post。

报价（如果它处于脱机状态）：

我下意识的反应是，=会更快，但我认为它，实现查询优化器就会真的发现作为同样的事情。根据快速创建的tbFoo对的查询计划进行检查以确认它。这就是我告诉他的。

除了我稍后意识到有一个主要警告 - 查询优化取决于语句是如何参数化的。如果它是纯粹特设的SQL并且在运行时编译，那么语句是等同的，但是如果要重新使用计划，可以将语句包含在存储过程中或准备执行并执行它通过sp_executesql，LIKE将施加显着的惩罚。

这是因为优化器在编译时并不知道参数LIKE操作是否会包含通配符，所以它不能使用更具体的优化（包括指数选择），它可能用=运算符。所以如果你大部分参数没有通配符，你将会执行一个次优的查询计划。在设计您的查询时请记住！

来源

2011-11-17 07:30:34

+1，但请将该帖子的结论复制到您的答案中，以便即使博客在某些时候不可用，答案仍然相关。 –

@DavidHedlund，好点，我贴了它。 –

这很容易测试。我使用了一个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">，即使没有%。

来源

2011-11-17 07:55:11

我不确定我是否同意它“很容易测试”。我更喜欢这里的规范参考;似乎有太多的变量可以可靠地纠正。你是否清除每个查询之间的统计信息如果不是这样，那么你刚刚运行几乎相同的查询的事实可能解释为什么第二次更快？请注意'xx％'在CPU时间内是如何更便宜的，但总体执行速度仍然低于'= xx'。难道是SQL服务器 - 或只是那台机器 - 正在完全影响性能？ –

@DavidHedlund - 机器是我的本地工作站。我没有清除运行之间的任何内容，所以整个表都在内存中。我连续不断地运行测试，并在不同的语句之间移动了顺序。运行之间存在细微差异，但这里的数字显示了不同方式之间的关系。 –

@DavidHedlund我不会得出'喜欢'xx％''比'='xx''更快的结论，但由于某种原因，它**比'like'xx''快。 –

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

回答

相关问题