最小化捕捉的事件数量避免SQL Server浪费宝贵的资源带宽去生成所有的事件。捕捉像锁和执行计划这样的事件时应该小心进行，因为这些事件会使跟踪输出变得非常大并降低SQL Server的性能。

　　过滤分两个阶段：预过滤由SQL Server执行，后过滤由用户执行。预过滤是捕捉SQL Server活动的联机阶段，预过滤提供多种溢出：

　　预过滤的唯一缺点是，可能丢失一些彻底分析中需要的重要信息。

　　2、丢弃性能分析所用的启动事件

　　所用于性能分析的信息围绕一个查询的资源开销。想SP:StmtStarting这样的启动事件不提供这种信息，因为只有在事件完成之后，才能计算I/O量、CPU负载和查询的持续时间。所以，在跟踪运行缓慢的查询以进行性能分析时，不需要捕捉启动事件。这种信息由对应的完成事件来提供。

　　什么情况下适合捕捉启动事件呢？应该在预期某些SQL查询因为错误而不能结束执行，或者频繁发现Attention事件的时候捕捉启动事件。Attention事件一般表示用户中途撤销了查询或者查询超时，可能因为查询运行了太长时间。

　　3、限制跟踪输出大小

　　除了预过滤事件和数据列，其他过滤条件也会限制跟踪输出的大小。同样，限制大小可能丢失所关注的总体系统状态中感兴趣的事件。但是，如果关注于开销较大的查询，过滤器是有帮助的。

　　通过过滤器，能够筛选执行事件》=2或逻辑读数量》=100的查询，因为消耗太低的查询基本上不需要优化。

　　4、避免在线数据列排序

　　在性能分析期间，一般在不同的数据列(如Duration、CPU、Reads)上排序以确定相应数字最大的查询。如果脱机排序，就能降低在与SQL Server交互时必须进行的Profiler活动。排序捕捉到的SQL跟踪输出的方法如下：

　　5、远程运行Profiler

　　直接在生产服务器上运行测试工具一般不是一个好办法。Profiler有一个大型的用户界面，因此，在其他机器上运行它更好。与系统监视器相似，Profiler不应该通过终端服务会话来运行，因为这样工具的主要部分仍然在服务器上运行。在直接将跟踪输出收集到一个文件时，保存在Profiler运行的本地文件上。这仍然是比通过系统存储过程将Profiler作为服务器端跟踪来运行更加资源密集的操作。使用系统存储过程仍然是最好的选择。

　　6、限制使用某些事件

　　某些事件的开销比其他的事件大。由于生成的查询的特性，语句完成事件的开销可能非常大。需要谨慎地使用，特别是在已经遇到压力的系统上，必须谨慎使用的事件有：Showplan XML事件，Performance:Showplan XML、Performance:Showplan XML for Query Compile和Performance:Showplan XML sTATISTICS Prifile。虽然这些事件可能有用，但是不要在生产机器上使用它们。

五、没有Profiler的情况下查询性能度量

　　建立一个跟踪能收集许多数据供以后使用，但是这种收集可能代价很大，必须等待结果。

　　如果要立即捕捉系统的性能度量，特别是关于查询性能的度量，那么动态管理视图sys.dm_exec_query_stats正式所需要的。如果还需要查询运行及其单独开销的历史记录，那么跟踪仍然是更好的工具。但是，如果只需要知道这时候运行时间最长的查询或者最多的物理读操作，则可以从sys.dm_exec_query_stats得到这些信息。

　　因为sys.dm_exec_query_stats只是一个视图，可以简单地对其进行查询并获得服务器上查询计划统计的信息。

　　为了过滤从sys.dm_exec_query_stats返回的信息，需要将其连接到其他动态管理函数上，如sys.dm_exec_sql_text可以显示与计划相关的查询文本，sys.dm_query_plan显示用于查询的执行计划。一旦连接到其他DMF，可以限制希望过滤得数据库或过程。