我想调整生产SQL Server。进行了调整(例如更改并行度)之后，我想知道它是否有助于或者损害了查询执行时间。

这似乎是一个明显的性能计数器，但是在过去的半小时中，我一直在搜索Google和perfmon中的计数器列表，而且我无法找到SQL Server的性能计数器来给我所有服务器的平均执行时间。查询命中服务器。 SQL Server的ASP.NET请求执行时间。

是否存在我想念的东西？还有另一种有效的方法来监视服务器的平均查询时间吗？

解决方案

在什么时间和哪些查询上取平均值？我们需要进一步定义"平均"的含义，或者它没有任何意义，这可能就是为什么它不是简单的性能计数器的原因。

我们可以通过运行跟踪来捕获此信息，然后将其捕获到表中，然后可以通过多种方式之一将执行时间切分和切块。

我们可以使用查询分析器(这是SQL Server的工具之一)，并查看它们在内部的执行方式，以便优化索引等。这不会告诉我们平均值，也不是返回客户端。为此，我们必须将其记录在客户端上并自己分析数据。

它不能完全满足需求，但我强烈建议我们尝试使用SQL Server 2005性能仪表板报告，该报告可在此处下载。它包括前20条查询及其平均执行时间的报告，以及许多其他有用的报告(按IO，等待统计等列出的前查询)。如果要安装，请务必注意其安装位置，并按照"其他信息"部分中的说明进行操作。

探查器将为我们提供有关服务器上查询执行时间和活动的统计信息。如果不将整体查询时间与特定作业和查询计划联系在一起，那么总查询时间可能会或者可能不会非常重要。

性能瓶颈的其他指标是资源争用计数器(常规统计信息，闩锁，锁)。我们可以通过性能计数器看到这些。另外，如果查找大量的表扫描或者其他不使用索引的操作，可能会提示我们可能需要建立索引。

在已加载的服务器上，增加并行性不太可能对性能产生实质性影响，因为在任何给定时间已经有许多查询处于活动状态。并行性使我们获得成功的地方在于不经常运行的批处理作业，例如ETL流程。如果我们需要减少此类过程的运行时间，那么并行度可能是一个不错的选择。在繁忙的服务器上与许多用户一起执行事务性工作负载时，系统资源将因工作负载而变得繁忙，因此并行性不太可能成为大赢家。

我不相信有PerfMon，但是SQL Server Management Studio中有一份报告：

右键单击数据库，选择"报告">"标准报告">"对象执行统计信息"。这将为我们提供有关数据库中正在运行的内容，所需的时间，所需的内存/ io处理的数量等非常好的统计信息。

我们也可以在所有数据库的服务器级别上运行此命令。