执行某些SQL join使您的ASP.NET应用程序非常慢

本文关键字：NET ASP 应用程序非常 SQL join 执行 | 更新日期: 2023-09-27 18:13:00

我说的是使应用程序爬行的某些SQL JOIN(不是全部)。我曾经在我的代码中产生过这个，我认为这真的是微软的一个bug。问题是，查询在SQL Management Studio中执行得很好，但在您的应用程序中，它使一切停止10秒以上，除非查询完成。我认为这真的是一个bug。

微软bug/反馈网站中有一个例子。从一页翻到另一页需要8秒。看在上帝的份上，他们就不能优化一下吗?我认为这是那个bug的表现。

有人遇到过吗?有人能认出来吗?我正试图解决我自己的慢查询，但想先澄清这一点。

你需要阅读和理解这一点:在应用程序慢，在SSMS快?理解性能之谜(Erland Sommarskog)

目录如下:

数据大小是一个变量，它将彻底改变管理工作室与制作工作室的性能。

另一个变量是从查询返回的数据-如果你是在本地sql管理工作室vs.远程拉，以及c#代码本身-它是如何处理这些数据的。

Sql Server还会根据统计数据生成查询计划。查询计划决定使用哪些索引。您应该捕获查询计划。如果这是一个问题，您还可以提供查询计划提示来使用某些索引。

你需要分析你的c#代码并分析你的查询计划。如何阅读和优化查询计划超出了SO答案的范围。

我从来没有注意到一个在管理工作室中执行良好的查询，当我从我的应用程序运行它时，它无法执行。当然，有些SQL连接明显比其他连接慢，但你不应该看到一个1秒的查询执行20秒或类似的事情。

要记住的一件事是，ASP网页无论如何都会比存储过程的执行时间稍慢。当你在管理工作室中运行查询时，你只是在运行查询，但是当你从服务器请求一个页面时，必须打开到数据库的连接，查询必须被执行，然后页面必须呈现从查询中检索到的数据，所以这增加了查询执行时间的开销，你可能会注意到。

你有一个你自己的代码的例子，我们可以看看吗?

我刚刚检查了微软的网站，响应时间真的很糟糕，我不敢相信有人会让这样的东西上线。

检查您的程序和SSMS中的默认设置。例如，如果在SSMS中运行SET ARITHABORT OFF，您可能会发现它现在运行起来和运行您的程序一样慢。

我曾经发现SSMS中的SET ARITHABORT OFF会导致存储过程被重新编译和/或使用不同的统计数据。突然之间，SSMS和我的程序都报告了大致相同的执行时间。

要检查这一点，请查看每次运行的执行计划，特别是syscacheobjects表。它们可能会有所不同。

最后，您可以尝试使用SSMS清理过程缓存和内存缓冲区:

DBCC DROPCLEANBUFFERS 
DBCC FREEPROCCACHE

在测试查询之前这样做可以防止使用缓存的执行计划和先前的结果缓存。

这实际上取决于查询和连接。连接本身，无论什么类型，都不会影响您所引用的性能。