在我们的生产环境（SQL Server 2008 Enterprise）中，我们遇到了CPU使用率和networking利用率方面的问题。 根据我们拥有的（多个）机器的规格和软件产品的一般function，负载不应该成为问题。
作为一名开发人员，我认为这个问题必须存在于其他地方，可能在正在运行的查询中。 我认为将SQL事件探查器附加到生产实例以确定哪些查询（甚至是代码）是热点是一个好主意，并且首先优化这些区域。 （我们的硬件/networking人员都没有做过。）
我将探查器连接到我们的开发实例几个小时，并确定我们有几个问题领域：
SELECT *查询出现; 也有不less是非参数化的。 这是＃1的一个大的子集，其中一个查询只会因一个WHERE参数而异。 根据我生成的摘要统计，最大的问题查询是types＃1和＃2。 但是，我不能立即采取这些结果并开始工作，因为开发实例查询本质上是当时其他开发人员正在进行的工作，而不是在生产中运行最多的。
我一直在阅读，因为开销，将SQL Server Profiler附加到实例是有问题的。 出于显而易见的原因，附加在生产环境中应尽可能轻。
我需要知道的是 – 鉴于我需要查明的三种不同types的查询，我如何设置分析器对性能影响最小？ 还有另外一个工具可以用来完成这个工作吗？
笔记：
而不是附加SQL PRofiler，请使用sp_trace_xxx过程。 SQL Profiler之所以不被推荐用于生产，是因为它可能导致服务器在等待与Profiler进行networking通信时发生阻塞（“networking”意味着本地共享内存，位置不相关）。 这个想法是，单线程GUIpipe理的进程将无法跟上来自multithreading本地高度优化服务器的全速事件stream。 通过使用Trace过程，您可以将GUI / Profiler从等式中解脱出来，并让服务器尽可能快地刷新事件，因为事件可以写入服务器上的磁盘上，这总比事件探查器能够快得多来处理它们。 如果你在事件上添加一个体面的filter（例如，只跟踪RPC：完成和批处理：持续时间高于1秒的完成事件或类似情况），那么你将不会对服务器产生严重的影响。
GUI Profiler能够将跟踪保存为一系列的sp_trace调用，因此您不必手动创build脚本。
理想情况下，您也可以有一个分段或testing环境，在其中放置要testing的代码，而不是开发，然后对其进行生产级别的加载。 在这种情况下，您需要首先加载生产代码和数据库的副本，启动分析器，然后让用户或testing人员像使用生产系统一样使用它。
一旦你完成了这些工作，并对一些事情进行了优化，你就可以把这些代码加载到你的testing环境中，再次testing一下，看看是否会发现另一个瓶颈。
现在，如果你不能做到这一点，你应该有一个想法，即在你的开发环境中运行探查器，如果它足够轻量级（或不是）直接尝试对产品运行。
探查器从不同的服务器/工作站运行。