使用场景
记得某次给一家公司调优的时候，负责人发给我一堆业务的T-SQL脚本，我面对海量脚本还是从容，虽然不了解内部复杂的业务，但是我们得专注问题的关键 “慢”，我们根据查询的“慢”把他们筛选出来，一一调式优化，不就迅速解决问题吗？三天后，负责人含泪握着我的手，哥们辛苦了，查询响应得到了质的改善。
跟踪提供者
SQL Server 为我们两者提供跟踪的方式：一种是一个物理文件（可保存在本机或者UNC网络路径），一种是行集。对于后者大家应该比较熟悉
这个工具在 SSMS 的 工具 –> SQL Profile
详细的我暂时不介绍，先说说两者的区别和类同点 DIFFAndSame（行集，文件提供者）。
两者都是用类似Buffer来保存当前的事件数据，很明显是为了减少IO的压力，这样可以不阻塞和尽量不遗漏 事件数据，当Buffer 到达一定量时候可能才会Flush到磁盘或者发送到网络的终端（客户端）显示监控行集。
物理文件保存监控结果的方式的重要保证是不能遗漏任何事件，一旦IO降速的时候，可能会影响到整个T-SQL的执行情况。
| 以下是代码片段： SELECT * FROM sys.dm_os_wait_stats WHERE wait_type IN ('SQLTRACE_LOCK','IO_COMPLETION'); |
我使用这个语句来监控TRACE 和IO 完成对我当前机器的影响，我的某个客户的IO情况：
| 以下是代码片段： wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms IO_COMPLETION 66030898 24377499 3634 418960 SQLTRACE_LOCK 12007 175943 1001 1281 |
因为我进行了大量的过滤，因此这个值还是能够接受的，影响不是特别大。
行结果集的方式，其实也是我们最熟悉的，就是使用SQL Server Profile监控GUI 直接展现给我们看到的。但是，我是非常不建议使用的，首先如果Buffer满了，它有一定的延迟，可能会抛弃事件已清空缓存区继续接受事件，而事件没有发送到Client，也没有写到物理文件，自然就丢失了。比如，SQL Server Profile 在DB服务器进行监控，因为高负载的机器再用来展示，很有可能就会丢失事件，另外物理文件方式，其实是接受一个足够大的Buffer，进行的大块写操作，性能是优于行集的。
保密性原则
SQL Server的安全特性会自动过滤 包含隐私的数据，比如密码。我在我的SSMS中执行了如下的语句：
| 以下是代码片段： EXEC sp_password 'pp','pp1','sa'; |
这是修改sa帐号密码的系统sp，我打开了SQL Server Profile –> 选择了T-SQL 监控模版
然后执行上面的存储过程，监控结果：
监控结果：--*sp_password----------------------------
SQL Server Profile
