SQL Server PerfMon：编译/秒 > 批处理请求/秒

Question

我一直在查看我们客户的一个 SQL Server 实例上的各种 PerfMon 指标，试图很好地衡量我们的数据库（或服务器）可以在哪里使用改进。

让我感到困惑的一项衡量标准是两个 PerfMon 指标的比率：编译/秒和批处理请求/秒。

根据这篇文章，“一般的经验法则是编译/秒应为总批处理请求数/秒的 10% 或更少”。

我们的应用程序有一个 Windows 服务，它每小时对数据库调用一次预定计算。就像发条一样，在我的 PerfMon CSV 数据中，我可以看到 Compilations/sec 和 Batch Requests/sec 的峰值。我没想到的是编译数/秒超过了批处理请求/秒。

我正在查看来自 PerfMon 的 15 秒样本，这些样本以我们的计算开始的时间为中心：

这通常表明什么？这甚至有意义吗？为什么我们要编译更多的语句而不是执行？我错过了什么吗？

Answer 1

抱歉，不要贬低托马斯的建议，但请对“一般规则”持保留态度，或者干脆把它们扔出窗外。

基线。

你的系统什么是正常的？系统当前是否响应正常？

如果没有性能问题，请不要尝试将您的系统与某些人从空气中提取的数字或可能基于几年前某些非常特定的系统和工作负载的数字进行比较，并放弃一切以尝试“修复”它。

具体来说，批处理请求和编译在所有场景中都没有非常好的和方便的关联。在开始恐慌之前，您需要了解您的工作量，因为您的计数器达到了某人在某处发布的某个阈值。如果您的所有批次都只包含一个语句，那么是的，每秒编译次数多于批量请求/秒可能看起来不寻常（但仍然可能并不表示有问题）。在大多数情况下，您批量发送多个语句。如果是这种情况 - 特别是如果您使用 ORM 或许多高度可变的动态 SQL 之类的东西，您将遭受大量编译的困扰 - 看到一个计数器比另一个高，我真的不会感到惊讶.

在那种情况下，您是否需要对此做些什么是一个完全不同的问题。