在我们的生产环境 (SQL Server 2008 Enterprise) 中，我们一直遇到 CPU 使用率和网络利用率问题。根据我们拥有的 (多台) 机器的规格以及我们软件产品的一般功能，负载不应该是一个问题。
作为一名开发人员，我认为问题一定出在其他地方，可能是正在运行的查询。我认为将 SQL Profiler 附加到生产实例以找出哪些查询（甚至代码）是热点，并首先优化这些区域是一个好主意。（我们的硬件/网络人员以前都没有这样做过。）
我将分析器附加到我们的一个开发实例上几个小时，并确定我们存在几个问题区域：
- 在循环内执行的查询——经常会看到相同的几个查询被执行数万次。
- 未缓存的查询 - 我看到
SELECT *出现了几个查询；还有相当多的查询是非参数化的。这是 #1 的一个很大的子集，其中查询只会因一个WHERE参数而变化。 - 长时间运行的查询 - 实际上正在占用 CPU 的查询；这些查询可能是低效编写的、没有使用索引等。这些查询的命中率要低得多。
根据我生成的汇总统计信息，问题最大的查询属于类型 #1 和 #2。但是，我无法立即获取这些结果并开始工作，因为开发实例查询本质上是其他开发人员当时正在处理的查询，而不是生产中运行最多的查询。
我读到过，将 SQL Server Profiler 附加到实例会因为开销而出现问题。出于显而易见的原因，在生产环境中附加应该尽可能轻量。
我需要知道的是——考虑到我需要发现的三种不同类型的查询，我该如何设置分析器以将对性能的影响降到最低？还有其他工具可以用来实现这一点吗？
笔记：
- 我们的生产环境有明确的高峰和非高峰时间，因此在高峰时段仅捕获 30-60 分钟的数据就可能获得不错的样本。
- 我想记录到数据库——在使用分析器之后，该日志格式以后是最容易使用的。
答案1
不要附加 SQL PROfiler，而是使用sp_trace_xxx程序。不建议在生产中使用 SQL Profiler 的原因是，它会导致服务器在等待与 Profiler 的网络通信以刷新时阻塞（“网络”可以表示本地共享内存，位置无关紧要）。这个想法是，单线程 GUI 管理进程无法跟上来自多线程本机高度优化服务器的全速事件流。通过使用跟踪程序，您可以将 GUI/Profiler 排除在等式之外，并让服务器以事件写入服务器磁盘的速度刷新事件，这总是比 Profiler 处理它们的速度快得多。如果您在事件上添加一个合适的过滤器（例如，仅跟踪持续时间大于 > 1 秒或类似时间的 RPC:Completed 和 Batch:Completed 事件），那么您将不会对服务器造成任何严重影响。
GUI Profiler 能够将跟踪保存为一系列 sp_trace 调用，因此您不必手动创建脚本。
答案2
理想情况下，您还可以拥有一个临时或测试环境，将要测试的代码（而不是开发的代码）放入其中，然后对其施加生产级负载。在这种情况下，您首先要加载生产代码和数据库的副本，启动分析器，然后让用户或测试人员像使用生产系统一样使用它。
完成这些并优化一些内容后，您可以将该代码重新加载到测试环境中，然后再次测试，看看是否发现另一个瓶颈。
现在，如果您不能这样做，您应该通过在您的开发环境中运行分析器来了解它是否足够轻量（或不够）以尝试直接在生产中运行。
答案3
让分析器从不同的服务器/工作站运行。