如何分析从ASP.NET应用程序运行的一些查询？由于数据库(我认为)，我工作的某些软件运行非常慢。这些表具有索引，但是它仍在拖动，因为它正在处理大量数据。如何剖析我在哪里可以进行一些小的改进，从而有望带来更大的速度改进？

编辑：我想补充一点，网络服务器喜欢在这些长查询期间超时。

解决方案

若要分析SQL Server，请使用SQL事件探查器。

而且，我们可以使用Red Gate的ANTS Profiler来分析代码。

Sql Server有一些出色的工具可以解决这种情况。这些工具内置于Management Studio(以前称为企业管理器+查询分析器)中。

使用SQL事件探查器向我们显示来自Web应用程序的实际查询。

复制出每个问题查询(那些消耗大量CPU时间或者IO的查询)。使用"显示实际执行计划"运行查询。希望我们会看到一些明显的索引丢失。

我们还可以运行调整向导(该按钮位于"显示实际执行计划"旁边。它将运行查询并提出建议。

通常，如果我们已经有索引并且查询仍然运行缓慢，则将需要以其他方式重新编写查询。

将所有查询保留在存储过程中会使这项工作变得更加容易。

我相信我们已经找到了分析查询所需的答案。但是，这是性能调整中最简单的部分。一旦知道了查询而不是网络或者应用程序，如何找到并解决问题？

性能调优是一件复杂的事情。但是首先要看一些地方。我们说我们要返回大量数据？我们返回的数据是否超出需求？我们是否真的只返回所需的列和记录？使用select *返回100列可能比返回实际使用的5列要慢得多。

索引和统计信息是最新的吗？如果我们有一段时间没有这样做，请查找如何在BOL中更新统计信息并重新编制索引。我们在所有联接字段上都有索引吗？ where子句中的字段如何？

你用过光标吗？我们是否使用过子查询？联合怎么样—如果我们正在使用它，可以将其更改为全部联合吗？

查询是否可靠(如果不熟悉该术语，则为Google。)

可以使用分组依据时，我们是否使用"与众不同"？

你有锁吗？

还有很多其他的东西只是起点。

另一个可与ASP.NET完美配合的.NET探查器是dotTrace。我亲自使用过它，并在我的代码中发现了很多瓶颈。

如果存在要调整的特定查询或者存储过程，我发现在查询之前打开统计信息非常有用：

SET STATISTICS TIME ON
SET STATISTICS IO ON

当我们在查询分析器中打开统计信息时，统计信息将显示在"结果"窗格的"消息"选项卡中。

IO统计信息对我特别有用，因为它可以让我知道是否需要索引。如果我从IO统计信息中看到较高的读取计数，则可以尝试向受影响的表中添加不同的索引。在尝试索引时，我再次运行查询以查看读取计数是否减少。经过几次迭代后，我通常可以找到所涉及表的最佳索引。

这是这些统计信息命令的MSDN链接：

设定统计时间

设定统计资料IO