一位同事最近遇到了这样一种情况，即使用 UserID（即 UNIQUEIDENTIFIER）上的 = 比较来查找安全权限的查询需要大约 15 秒才能运行。不用说，用户并没有留下深刻的印象。
出于沮丧，我的同事将 = 比较改为使用 LIKE，查询速度加快到不到 1 秒。
在不了解数据架构的情况下（我无权访问数据库或执行计划），什么可能导致这种性能变化？
（我知道这个问题广泛而模糊）
【问题讨论】：
标签： sql-server database sql-server-2005 tsql
可能只是一个糟糕的执行计划被缓存了；然后更改为 LIKE 语句只会导致生成新的执行计划。如果此人在相关表上运行 sp_recompile 然后重新运行 = 查询，则可能会注意到相同的加速。
【讨论】：
另一种可能性是，这是一个复杂的查询，并且每行的 = 运算符都会发生类型转换。 LIKE 稍微改变了语义，这样类型转换就不必在执行计划中占据很大的比重。我建议你的同事看看带有 = 的执行计划，看看是否有类似
CONVERT(varchar, variable) = othervariable
在执行步骤中。在错误的情况下，单个类型转换会使查询速度降低两个数量级。
【讨论】：
在某些情况下，当可以使用索引时，LIKE 可以比 SUBSTRING 等等效函数更快。
你能给出确切的SQL吗？
有时函数会阻止优化器使用索引。
比较执行计划。
【讨论】：
好吧，如果他一个接一个地运行两个查询，那么很可能第一个查询的数据必须从磁盘读取，但第二个查询仍然在 RDBMS 数据缓存中......
如果发生了这种情况，那么如果他以相反的顺序运行它们，他会看到相反的结果......如果他使用 like 和一个确切的值（没有通配符），那么查询计划应该是相同的......
【讨论】：
您是否尝试过更新此表/数据库的统计信息？可能值得一试。
【讨论】：