RAM 中的逻辑读取是否出现在等待统计信息中或在哪里？

Question

关于 SQLOS 的执行模型（RUNNING 状态、RUNNABLE 队列、WAITER 列表），当当前正在进行 RAM 中页面的逻辑读取时，任务的状态是什么？

如果是 WAITER 列表，最流行的等待类型是什么？

我可以以某种方式测量此类操作所需的时间吗？

我知道很多逻辑读取会减慢您的查询速度，很多表/索引扫描（已经位于缓冲池中）会减慢您的查询速度 - 我只想知道它们如何出现在统计信息/dmv 中或如何将其与其他数据区分开来“经典”等待类型。

Answer 1

当工作人员需要等待某种资源时，它会进入服务员名单。没有资源可以等待逻辑读取。假设您的缓冲池没有分页，数据已经在 SQL Server 管理的内存中。执行大量逻辑读取的查询很慢，因为它们花费大量 CPU 来执行这些逻辑读取。

如果您想了解 SQL Server 在执行逻辑读取时正在执行的内部操作，那么您可以在运行受到逻辑读取瓶颈的查询时使用perfview或其他一些工具进行 ETW 跟踪。如果您认为您的工作负载存在内存吞吐量问题，那么 ETW 跟踪可能是一个很好的步骤。请注意，情况可能并非如此，以下演示几乎肯定是解决查询性能问题的错误方法。

首先，我将编写一个我希望将大部分时间用于逻辑读取的查询：

DROP TABLE IF EXISTS #215016;

SELECT 1 ID, REPLICATE('Z', 1000) FILLER INTO #215016
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

SELECT t1.ID, t2.ID
FROM #215016 t1
INNER JOIN #215016 t2 ON t1.ID < t2.ID
OPTION (MAXDOP 1, QueryRuleOff BuildSpool);

SQL Server 在整个查询执行过程中使用了完整的 CPU 核心。以下是从 10 秒样本中获取的 perfview 结果：

也许圆圈中的方法名称是您感兴趣的。对于这个查询，SQL Server 将大约 5% 的 CPU 时间花在 上sqlmin!BPool::Get，我认为这与实际执行逻辑读取有关。为了捍卫这个想法，该方法sqlmin!BUF::AcquireLatch大部分时间都在调用：

并且在查询期间获取的共享锁存器的数量与逻辑读取的数量大致相同。但这只是一个猜测，因为 Microsoft 没有记录方法名称，而且我不知道“逻辑读取”的完整范围。