一位同事最近遇到了这样一种情况：查询安全权限需要大约15秒才能使用= UserID（这是一个UNIQUEIDENTIFIER）进行比较。毋庸置疑，用户不会留下深刻的印象。
出于沮丧，我的同事改变了=比较以使用LIKE并且查询加速到1秒以下。
在不了解数据模式的情况下（我无权访问数据库或执行计划），可能会导致性能发生这种变化？
（广泛而含糊的问题，我知道）
答案 0 :(得分：8)
它可能只是一个缓存的糟糕的执行计划;更改为LIKE语句然后只是生成了一个新的执行计划。如果此人已在相关表上运行sp_recompile然后重新运行=查询，则可能会注意到相同的加速。
答案 1 :(得分：8)
另一种可能性是，这是一个复杂的查询，并且每行都在=运算符之间进行类型转换。 LIKE稍微改变了语义，以便类型转换不必在执行计划中占据重要地位。我建议你的同事看看执行计划中的=到位，看看是否有像这样的东西
CONVERT(varchar, variable) = othervariable
在执行步骤中。在错误的情况下，单个类型转换可以使查询减慢两个数量级。
答案 2 :(得分：1)
在某些情况下，当可以使用索引时，LIKE可能比SUBSTRING等效函数更快。
您能准确提供SQL吗？
有时，函数可以阻止优化器使用索引。
比较执行计划。
答案 3 :(得分：1)
好吧，如果他一个接一个地运行这两个查询，那么很可能数据必须从磁盘读取第一个查询，但仍然在第二个查询的RDBMS数据缓存中......
如果发生了这种情况，那么如果他以相反的顺序运行它们，他会看到相反的结果......如果他使用了精确值（没有通配符）那么查询计划应该是相同的..
答案 4 :(得分：0)
您是否尝试更新此表/数据库的统计信息？可能值得一试。