GridView + ObjectDataSource 问题 - 大型和小型结果集的性能同样糟糕答案

【问题标题】：GridView + ObjectDataSource issue - equally bad performance for large and small result setsGridView + ObjectDataSource 问题 - 大型和小型结果集的性能同样糟糕
【发布时间】：2009-05-03 21:49:02
【问题描述】：

我最近被要求开发一个较旧的 .NET 旧版 Web 应用程序。由于系统中的数据量翻了两番，性能最近下降得相当低。前 2 年一直很好。

它使用 .xsd 文件与存储过程通信，该存储过程充分缩小了结果范围（尽管没有分页），并通过 ObjectDataSource 将它们输入到 GridView。

我无法理解的部分，加载 1 个结果（140 或 1200）大约需要 7 秒。它需要拆分在 0 结果案例中排名第二。（GridView 正在处理分页）

使用 SQL 分析器，我们可以看到查询花费了 6.9 秒。在 SQL Management Studio 中使用相同的参数运行相同的查询需要 100 毫秒。我改变了参数以确保它不仅仅是一个缓存的结果。漫长的等待时间可以可靠地重现。

我知道 implementing paging 需要在这里完成，但现在我只是回顾性地试图找到一个解释为什么页面在大小方面表现同样糟糕套...

（GridView 的“简单”显示可以满足他们的需求 - 无需控制 HTML）

【问题讨论】：

我注意到在查询分析器中执行查询时（自 2000 版本以来没有使用 MSSQL），如果它在 Results in Text 中执行，它比 慢网格中的结果。我认为 GridView（因为它是 HTML）与 Text 中的结果具有相同的性质，因此 GridView 速度较慢，即它需要先计算空格的大小、格式等，然后才能轻松显示结果

标签： asp.net sql performance gridview

【解决方案1】：

我们也有同样的问题：

检查您的统计信息是否是最新的：

选择 ObjectName = Object_Name(ind.object_id), IndexName = ind.name, StatisticsDate = STATS_DATE(ind.object_id, ind.index_id) FROM SYS.INDEXES ind 按 STATS_DATE(ind.object_id, ind.index_id) desc 排序

删除 SQL 服务器缓存：

DBCC 删除缓冲区 DBCC FREEPROCCACHE

如果两者都没有帮助，您可以尝试使用“inner LOOP join”和“with (index=...)”等提示强制执行 SSMS 查询计划。

【讨论】：

【解决方案2】：

您可以尝试查看应用程序发送的执行计划和参数类型。例如，如果您的应用程序传递 nvarchar 以与 varchar 列进行比较，则可能会导致问题。 http://weblogs.sqlteam.com/tarad/archive/2007/11/16/60408.aspx

【讨论】：