在跟踪我的 SQL Server 2008 Std Edition 安装的性能监视器时，我注意到 SQL Compilations/sec 每 5 秒左右出现一次峰值，从 3 到 50 左右。
我们的编译与批处理请求/秒的比率也相对较高。我知道理想情况下这应该是 1/10 的比率，但我们的工作比例更像是 8/10。
db 支持具有许多应用程序的繁忙网站，因此很难确定导致过度编译的原因，尤其是 5 秒的峰值。几乎所有查询都是存储过程调用而不是嵌入式 SQL，而且我们有大量 (48gb) RAM。
有没有办法在给定的时间查看当前正在编译的查询？如果是这样，我们可以解决是否有问题。
过去，当我不得不研究计划缓存/过度查询重新编译的问题时，我遵循了 Microsoft 白皮书“SQL Server 2008 中的计划缓存”中提供的指导</a>，我强烈建议将其阅读为它涵盖了计划缓存、查询计划重用、重新编译的原因、识别重新编译和其他相关主题。
话虽如此，SQL Server Profiler（如果您将其作为客户端工具安装的一部分安装，则应位于 Microsoft SQL Server 2008 -> Performance Tools 下）公开了三个与查询编译直接相关的事件，这些事件可能对您有所帮助：
您正在使用存储过程，因此您可能只需要担心SP:Recompile事件。每当重新编译存储过程、触发器或用户定义的函数时，都会触发此事件。TextData 列将显示导致语句重新编译的 tsql 语句的文本，EventSubClass 列将显示指示重新编译原因的代码。
SP 的 EventSubClass 代码：在 SQL 2008 中重新编译
如果您监视以下 5 个事件，您将能够看到 SQL Server 上正在调用哪些存储过程和语句，以及哪些正在触发重新编译：
我通常还设置 Profiler 跟踪以捕获这些事件的所有列。我会说使用这 5 个事件设置跟踪，运行 30 到 60 秒的跟踪，然后暂停它，然后您应该对导致重新编译的原因有一个很好的快照。
如果噪音太大，您可以开始将列过滤器添加到跟踪属性以过滤输入/输出事件。例如，如果您发现大多数重新编译只发生在一次数据库上，请在 databaseID 或 databaseName 列上设置列过滤器，以便仅针对该数据库运行的查询包含在您的跟踪中。
然后开始寻找正在重新编译查询的模式，并使用 Microsoft 的白皮书作为他们可能触发重新编译的指南。