在我的SQL Server 2008标准版安装上跟踪性能监视器，我注意到SQL汇编/秒的峰值每五秒钟左右，3〜50左右如何确定什么是SQL Server的编译
我们也有相对较高的编译率与批量请求/秒。我理解这应该是1/10的比例，但我们的工作更像8/10。
db支持一个拥有大量应用程序的繁忙网站，所以很难确定是什么导致了过多的编译，尤其是5秒的高峰。几乎所有的查询都是存储过程调用而不是嵌入式SQL，而且我们有大量（48GB）RAM。
有没有办法在特定的时间查看当前正在编译的查询？如果是这样，我们可以确定是否有问题。
当我必须查看计划缓存/过度查询重新编译问题时，我遵循了Microsoft白皮书‘Plan Caching in SQL Server 2008’中提供的指导，我强烈建议您阅读它，因为它涵盖了计划缓存，查询计划重用，重新编译原因，识别重新编译和其他相关主题。因此，SQL Server Profiler（如果您将它安装为客户端工具安装的一部分，应位于Microsoft SQL Server 2008下的“性能工具”下）公开与查询编译直接相关的三个事件，这些事件可能有所帮助你：
您在使用存储过程，从而有可能你只需要担心SP:Recompile事件。只要重新编译存储过程，触发器或用户定义函数，此事件就会触发。 TextData列将显示导致语句重新编译的tsql语句的文本，而EventSubClass列将显示指示重新编译原因的代码。
为SP EventSubClass代码：重新编译在SQL 2008
如果您监视以下5个事件可以查看哪些存储过程和语句正在SQL Server上调用，哪些正在触发重新编译：
我通常还会设置Profiler跟踪来捕获这些事件的所有列。我会说，用这5个事件设置一个跟踪，运行30到60秒的跟踪，然后暂停它，然后你应该有什么导致重新编译的快照。
如果噪声太多，您可以开始将列过滤器添加到跟踪属性以过滤输入/输出事件。例如，如果您发现大多数重新编译仅发生在一次数据库上，请在databaseID或databaseName列上设置列筛选器，以便在跟踪中包含针对该数据库运行的查询。
然后开始寻找重新编译查询的模式，并使用Microsoft的白皮书作为指导，说明为什么它们可能会触发重新编译。
非常有帮助，谢谢你，格伦。 – 2013-02-10 21:23:21