当数据通过页面压缩进行压缩时，当系统不受 CPU 限制并且 95% 的响应看到响应时间减少时，我试图找出导致某些响应时间增加的原因。
所以我所做的是跟踪它到系统中发生的单个进程，然后我对该进程进行概要分析以确定在此过程中触发了哪些 SP 和 UFN。我最初的想法是，我可以单独运行每个 SP 和 UFN，并查看查询计划以查看在哪里进行了全面扫描，这可能需要从压缩中解压缩数据，并可能导致等待触发。
所以我现在拥有的是：
- 具有所用参数的 SP 列表
- 运行 SP 的数据库
- 不受限制的管理员访问系统以重现问题
- 相关过程的轮廓跟踪
由于我必须对 35 个 SP/UFN 进行分类，所以我想知道缩小原因范围的最有效方法是什么。根据我使用该系统的经验，我可以推断出某些 SP 比其他 SP 更有可能是罪魁祸首，但我想尝试以更科学的方式缩小范围。是否有任何工具或方法可以帮助我找出最有可能的违规者？
如果我可以确定压缩时比不压缩时慢的对象，这将有助于告知我们围绕页面压缩的策略。
科学方法基于定期收集过程和程序性能信息，使用商业包或更本土化的解决方案。您也可以完全从头开始，从探查器或扩展事件中收集信息。重要的是定期捕获数据，并使其易于使用（例如使用
SSRS）。可用的历史信息使跟踪性能随时间的渐进变化变得容易，在资源需求增加之前预测它们，诊断突然的变化，以及识别和测试需要改进的地方。
关于后一点，我相信您的方法应该是这样的：
ROW和PAGE压缩这比事后尝试追踪复杂代码中的性能回归要容易得多，没有可比较的基线。
如果您确定这 35 个可编程程序是罪魁祸首，那么经过时间和缓存计划的配置文件/事件的组合，加上sys.dm_exec_query_stats应该会让您了解问题所在。
不过，@Paul 关于记录基线的评论很重要。