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