【问题标题】:Query 10 x faster in ASP.NET than in SSMS在 ASP.NET 中的查询速度比在 SSMS 中快 10 倍
【发布时间】:2016-09-02 15:21:35
【问题描述】:

我目前正在分析一个用 ASP.NET / VB 编写的 Web 应用程序的搜索功能。主页上的搜索功能从 Web 服务请求结果,该服务反过来执行 SQL 查询并将结果发回。

为了分析性能,我在本地调试了应用程序并将查询复制到 SSMS 以在 SET STATISTICS TIME ON 的情况下运行它。

当我运行应用程序并在浏览器的开发人员工具中检查对我的服务的请求的响应时间时,它们往往在 300 毫秒左右。当我将完全相同的查询复制到 SSMS 时,手动设置所有参数(例如“DECLARE @SearchTerm VARCHAR = '%foobar%'”),查询运行时间在 1500 毫秒到 2000 毫秒之间。

我发现无数次提到应用程序中的查询运行速度较慢,但​​没有说明为什么会发生相反的情况。

过去有没有人有过类似的经历或找到了这种行为的可能解释?

【问题讨论】:

  • 你能在分析器中看到哪些命令在从应用程序发送选择之前发送到数据库吗?
  • 也许这取决于您是运行存储过程还是直接查询。存储过程被编译并且可以使用不同的统计量。
  • 我不确定,但可能是参数嗅探的问题,而不是变量您可以尝试将“%foobar%”放在搜索查询中并检查是否也需要相同的时间?
  • @SagarShelke 实际上这可能是解释。当我使用声明参数运行查询时,我得到以下统计信息:CPU 时间 = 2555 毫秒,经过时间 = 1742 毫秒。但是,当我替换它们时,直接输入“%foobar%”,我得到:CPU 时间 = 3746 毫秒,经过时间 = 369 毫秒。随意张贴作为答案。知道为什么 CPU 时间实际上会增加吗?
  • 更改您的存储过程以包含 WITH RECOMPILE 语句。另请查看 Kendra Little 的以下文章:brentozar.com/archive/2013/06/… 和 brentozar.com/archive/2013/06/…

标签: sql asp.net sql-server database vb.net


【解决方案1】:

我不得不猜测,因为您没有包含查询及其关联的查询计划。我猜您在 SSMS 和 ASP 页面中使用不同的 @SearchTerm(和其他)值进行查询。该查询有一个查询计划,在您第一次使用时根据传入的参数进行了优化,当您从 SSMS 运行它时,它使用了不合适的查询计划(针对传入的不同参数)。

【讨论】:

  • 谷歌“参数嗅探”了解更多详情。
猜你喜欢
  • 2011-01-02
  • 2011-11-30
  • 1970-01-01
  • 1970-01-01
  • 2021-11-04
  • 1970-01-01
  • 1970-01-01
  • 2014-06-15
  • 2013-02-07
相关资源
最近更新 更多