我正在谈论使您的应用程序爬行的某些SQL JOIN（并非所有）。我曾经在我的代码中制作了这个，我认为它确实是微软的一个错误。问题是查询在SQL Management Studio中执行得很好但在您的应用程序中它使一切都停止了10秒以上，除非查询完成。我认为这确实是一个错误。
它的一个例子是here in the Microsoft bugs/feedback site。从一个页面到另一个页面只需要8秒钟。他们难道不能为了上帝而优化这个，如果可以的话？我相信这是该错误的表现。
有没有人遇到它，有人可以识别它吗？我正在尝试解决我自己的慢查询问题，但是想先澄清一下。
答案 0 :(得分：2)
您需要阅读并理解这一点：Slow in the Application, Fast in SSMS? Understanding Performance Mysteries by Erland Sommarskog
这是目录：
<强>简介
推定
SQL Server如何编译存储过程
什么是存储过程？
SQL Server如何生成查询计划
将查询计划放入缓存中
不同设置的不同计划
默认设置
声明重新编译的影响
迄今为止的故事
并非总是参数嗅探......
替换变量和参数
阻断
索引视图和索引计算列
链接服务器的问题
获取信息以解决参数嗅探问题
获取必要事实
哪个是慢声明？
使用Management Studio获取查询计划和参数
直接从计划缓存中获取查询计划和参数
从跟踪中获取查询计划和参数
获取表和索引定义
查找有关统计的信息
如何修复参数嗅探问题的示例
不解决方案
最佳指数取决于输入
动态搜索条件
检查索引
应用程序缓存的案例
修复错误的SQL
SQL Server如何编译动态SQL
什么是动态SQL？
生成动态SQL计划
动态SQL和计划缓存
在SSMS中运行应用程序查询
解决动态SQL中的参数嗅探问题
计划指南
进一步阅读
修订
答案 1 :(得分：2)
数据大小是一个变量，它将彻底改变管理工作室与生产中的性能。
另一个变量是从查询返回的数据 - 如果你在本地sql管理工作室而不是远程拉动，还有C＃代码本身 - 它对这些数据做了什么。
此外，Sql Server根据统计信息生成查询计划。查询计划决定使用哪些索引。您应该捕获查询计划。如果这是一个问题，您还可以提供查询计划提示以使用某些索引。
您需要分析您的C＃代码并分析您的查询计划。如何阅读和优化查询计划超出了SO答案的范围。
答案 2 :(得分：1)
我从来没有注意到一个在管理工作室中运行良好的查询在我从我的应用程序中实时运行时无法执行。当然，有些SQL连接明显比其他连接要慢，但你不应该看到1秒的查询需要20秒才能执行或类似的事情。
要记住的一件事是，ASP网页的运行速度会比存储过程的执行时间稍慢。在管理工作室中运行查询时，您只是运行查询，但是当您从服务器请求页面时必须打开到数据库的连接时，必须执行查询，然后必须使用从中检索的数据呈现页面查询，这会增加您可能会注意到的查询执行时间。
您是否拥有我们可以查看的代码的最新示例？
我刚刚检查了MS网站，响应时间真的很糟糕我不能相信有人会真的让这样的东西上线。
答案 3 :(得分：1)
检查程序和SSMS中的默认设置。例如，如果在SSMS中运行SET ARITHABORT OFF，您可能会发现它现在运行速度与运行程序时一样慢。
我曾经发现，SSMS中的SET ARITHABORT OFF会导致重新编译存储过程和/或使用不同的统计信息。突然间，SSMS和我的程序都报告了大致相同的执行时间。
要检查这一点，请查看每次运行的执行计划，特别是syscacheobjects表。他们可能会有所不同。
最后，您可以尝试使用SSMS清除程序缓存和内存缓冲区：
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
在测试查询之前执行此操作可防止使用缓存的执行计划和以前的结果缓存。
答案 4 :(得分：0)
这实际上取决于查询和连接。无论何种类型，自己加入都不会影响到你所指的程度。