解读SQL Server 性能优化指标

文章小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《解读SQL Server 性能优化指标》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

阀值：如果数值持续大于75%就表示存在瓶颈。

含义：这个计数器表示一个线程在特权模式下所使用的时间比例。当你的程序调用操作系统的方法（比如文件操作，网络I/O或者分配内存），这些操作系统的方法是在特权模式下运行的。

与%Privileged Time计数器正好相反，指的是在用户状态模式下（即非特权模式）的操作所花的时间百分比。

SQLServer进行的CPU使用情况

阀值：取决于处理器

含义：这个计数器表示处理器接收处理硬件中断所使用的时间比例。这个值间接指出产生中断的硬件设备活动，比如网络变化。这个计数器显著增加的话表示硬件可能存在问题。

阀值：平均值持续大于2那么表示CPU存在瓶颈

含义：如果就绪的任务超过处理能力线程就会被放进队列。处理器队列是就绪但是未能被处理器执行的线程的集合，这是因为另外一个线程正在执行状态。持续或者反复发生2个以上的队列则明确的表示存在处理器瓶颈。你也能通过减少并发取得更大的吞吐量。
你可以结合Processor/% Processor Time来决定增加CPU的话你的程序是否能够受益。即使在多处理器的电脑上，对于CPU时间也是单队列。因此，在多处理器电脑上，Processor Queue Length (PQL)的值除以用来处理负载的CPU个数。
如果CPU非常忙（90%以上的使用率），PQL的平均值也持续大于2/CPU， 这是应该存在CPU瓶颈而且能够从更多的CPU中受益。或者，你可以减少线程的数量以及增加应用程序层的队列。这会引起少量的Context Switching，但是少许的Context Switching对于减少CPU负载是有好处的。PQL大于2但是CPU使用率却不高的的常见原因是对CPU时间的请求随机到达而且线程却从处理器申请到不对称的CPU时间。这意味着处理器并不是瓶颈，而你的线程逻辑是需要改进的。

每秒的自动参数化尝试数。 其总数应为失败的、安全的和不安全的自动参数化尝试之和。 当 SQL Server 实例尝试通过将某些文字替换为参数来参数化 Transact-SQL 请求时，就会进行自动参数化，这样可以对多个相似的请求再次使用保存在缓存中的执行计划。 请注意，在更新版本的 SQL Server中，自动参数化也称为简单参数化。 此计数器不包括强制参数化。

每秒自动参数化尝试失败次数。 该值应很小。 请注意，在更高版本的 SQL Server中，自动参数化也称为简单参数化。

每秒收到的 Transact-SQL 命令批数。 这一统计信息受所有约束（如 I/O、用户数、高速缓存大小、请求的复杂程度等）影响。 批处理请求数值高意味着吞吐量很好。

每秒的 SQL 编译数。 表示编译代码路径被进入的次数。 包括 SQL Server中语句级重新编译导致的编译。 当 SQL Server 用户活动稳定后，该值将达到稳定状态。

每秒语句重新编译的次数。 计算触发语句重新编译的次数。 一般来说，这个数值最好较小。

好了，本文到此结束，带大家了解了《解读SQL Server 性能优化指标》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！