描述等待统计信息

  • 8 分钟

监视服务器性能的综合方法涉及评估服务器正在等待的内容。 等待统计信息很复杂，SQL Server 配备了数百种等待类型，用于监视每个正在运行的线程并记录线程正在等待的内容。

为了有效地检测和排查 SQL Server 性能问题，了解等待统计信息的工作原理以及数据库引擎在处理请求时如何使用它们至关重要。 通过此知识，可以更准确地查明瓶颈并优化性能。

等待统计信息如何运行的屏幕截图。

等待统计信息分为三种类型的等待：资源等待、队列等待和外部等待。

  • 当 SQL Server 中的工作线程请求访问线程当前正在使用的资源时，便会发生“资源等待”。 资源等待的示例包括锁等待、闩锁等待以及磁盘 I/O 等待。
  • 当工作线程空闲并等待分配工作时，便会发生“队列等待”。 示例队列等待是死锁监视和已删除的记录清理。
  • 当 SQL Server 等待外部进程（如链接服务器查询）完成时，便会发生“外部等待”。 外部等待的一个示例是与将大型结果集返回到客户端应用程序相关的网络等待。

可以检查 sys.dm_os_wait_stats 系统视图，以浏览执行的线程遇到的所有等待以及 Azure SQL 数据库的 sys.dm_db_wait_stats。 sys.dm_exec_session_wait_stats 系统视图列出活动等待会话。

通过这些系统视图，你可以大致了解服务器的性能，并随时识别配置或硬件问题。 此数据从实例启动时就一直保留，但可以根据需要清除数据以识别更改。

等待统计信息按服务器上的总等待数的百分比进行评估。

按百分比排序的前 10 个等待的屏幕截图。

sys.dm_os_wait_stats 中此查询的结果显示了等待类型，以及每个等待类型的等待时间百分比（等待百分比）和平均等待时间（以秒为单位）的聚合。

在这种情况下，服务器具有 Always On 可用性组，如 REDO_THREAD_PENDING_WORK 和 PARALLEL_REDO_TRAN_TURN 等待类型所示。 CXPACKET 和 SOS_SCHEDULER_YIELD 等待的百分比相对较高，表示此服务器面临一定的 CPU 压力。

由于 DMV 提供了自上次 SQL Server 启动以来累积时间最长的等待类型列表，因此定期收集和存储等待统计数据可以帮助你了解性能问题并将其与其他数据库事件相关联。

考虑到 DMV 为你提供了自上次 SQL Server 启动以来累积时间最长的等待类型列表，因此定期收集和存储等待统计数据可能有助于你了解性能问题并将其与其他数据库事件相关联。

SQL Server 中提供了多种类型的等待，但其中一些是常见的。

  • RESOURCE_SEMAPHORE - 指示查询等待内存变得可用，通常是由于对某些查询授予过多的内存。 此问题通常表现为长时间的查询运行时间，甚至超时。 这些等待类型的原因可能包括过时统计信息、缺少索引和高查询并发性。

  • LCK_M_X - 经常指示阻塞问题。 可以通过更改为 READ COMMITTED SNAPSHOT 隔离级别、优化索引以减少事务时间或改进 T-SQL 代码中的事务管理来解决此问题。

  • PAGEIOLATCH_SH - 此等待类型可能指示索引问题或缺少有用的索引，从而导致 SQL Server 扫描过多的数据量。 或者，如果等待计数较低，但等待时间较长，则可能表明存在存储性能问题。 可以通过分析sys.dm_os_wait_stats系统视图中waiting_tasks_count和wait_time_ms列的数据来计算特定等待类型的平均等待时间，从而观察此行为。

  • SOS_SCHEDULER_YIELD - 此等待类型可能表示高 CPU 利用率，这与大量的大型扫描或缺少索引相关，并且通常涉及大量 CXPACKET 等待。

  • CXPACKET - 此等待类型的高出现可能表示配置不当。 在 SQL Server 2019 之前， 最大并行度（MAXDOP）的 默认设置是对所有可用的 CPU 用于查询。 此外，并行度的成本阈值设置为 5，这可能会导致小型查询并行执行，从而限制吞吐量。 若要减少此等待类型，可以降低 MAXDOP 设置并增加并行成本阈值。 但是，CXPACKET 等待类型也可能表示 CPU 使用率过高，这通常可以通过索引优化来解决。

  • PAGEIOLATCH_UP - 数据页 2:1:1 上的此等待类型可能表示页可用空间 (PFS) 数据页上的 TempDB 争用。 对于每个数据文件，每 64 MB 数据有一个 PFS 页。 此等待通常是由于只有一个 TempDB 文件造成的，因为在 SQL Server 2016 之前，默认行为是对 TempDB 使用一个数据文件。 TempDB 的最佳做法是为每个 CPU 核心使用一个文件，最多使用 8 个文件。 还必须确保 TempDB 数据文件的大小相同，并且具有相同的自动增长设置，以确保均匀地使用它们。 SQL Server 2016 和更高版本控制 TempDB 数据文件的增长，以确保它们以一致且同步的方式增长。

除了前面提到的 DMV 之外，查询存储还会跟踪与特定查询相关的等待。 尽管查询存储跟踪的等待数据不如 DMV 中的数据那么精细，但它仍然是对查询所等待的内容的有用概述。