小编Sra*_*nda的帖子

我有以下问题，我的 TempDB 知识还没有涵盖这一点：

• 在 SSMS 中运行约 200 毫秒的分析查询，从应用程序启动时在 SQL Server 上继续运行 60 秒以上 - 这种情况只是偶尔发生，大多数时候问题并不存在
• 可运行/挂起查询的队列可能会增长到同一查询文本的数十个查询，其中一个 SELECT 查询是阻止其他相同 SELECT 的头阻塞程序
• 当可运行/挂起队列与基线相比开始显着增长时，对于相同文本和参数值的特定查询，最主要的等待是 SOS_SCHEDULER_YIELD 和 PAGELATCH_UP
• 当问题发生时，排队的数十个查询具有相同的文字参数值（轮班开始时间戳、员工 ID 和生产区域）
• 被挂起的查询（在我们的监控快照期间 - DBA Dash）将 PAGELATCH_UP 等待作为最主要的等待，并且它们正在等待 tempdb 中的 GAM 页面
• 当我使用在可运行/挂起队列中不断堆积的查询参数检查 SSMS 中的执行计划时，查询不会溢出到 tempdb

服务器、数据库和数据库流量的配置：

• 4 到 6 个核心（问题独立发生在具有不同核心数的两台不同服务器上）
• 4 - 6 个大小统一的 TempDB 文件
• 分配给实例的 40GB RAM
• 在特定数据库中，启用了 RCSI + 快照（因此 TempDB 受到攻击）
• 运行查询的两个表上没有发生删除，只有 INSERT 和 SELECT - 当时仅插入 1 行
• SELECT 通常会命中最年轻的记录（最近插入的记录）
• 服务器通常每秒处理 400 - 700 个批量请求；当问题出现时，与正常操作相比，它会达到峰值 1500，从而产生较高的 IO + CPU …

我一直在挠头，重新阅读MSFT帮助，但我仍然无法理解sys.dm_db_index_operational_stats和sys.dm_db_index_physical_stats中的forwarded_fetch_count和forwarded_record_count之间的区别。让我用下面的例子来说明我理解观点的问题。

我运行了以下查询：

;with heaps as ( \nselect \n    DB_NAME(DB_ID()) dbname, object_name ( p.object_id ) objname, sum(row_count) row_count,\n    DB_ID() database_id, p.object_id objectid\nfrom \n    sys.dm_db_partition_stats p\n    join sys.objects o on o.object_id = p.object_id \nWHERE \n    index_id = 0 and o.is_ms_shipped = 0 --and row_count > 0\n    group by p.object_id ) \nselect \n    h.*, \n    forwarded_fetch_count\nfrom heaps h\n    cross apply sys.dm_db_index_operational_stats(database_id, objectid, 0, null) ps\n    WHERE forwarded_fetch_count > 0 ORDER BY forwarded_fetch_count DESC\xc2\xa8\n

和

SELECT …