jericzech Asked: 2018-08-16 10:43:27 +0800 CST2018-08-16 10:43:27 +0800 CST 2018-08-16 10:43:27 +0800 CST RAM 中的逻辑读取是否出现在等待统计信息中或出现在何处？ 772 关于 SQLOS 的执行模型（RUNNING 状态、RUNNABLE 队列、WAITER 列表），当当前正在对 RAM 中的页面进行逻辑读取时，任务的状态是什么？ 如果是 WAITER 列表，最普遍的等待类型是什么？ 我能以某种方式测量这种操作所花费的时间吗？ 我知道很多逻辑读取会减慢您的查询速度，很多表/索引扫描（已经驻留在缓冲池中）会减慢您的查询速度 - 我只想知道它们如何出现在统计/dmv 中或如何将其与其他区别开来“经典”等待类型。 sql-server performance 1 个回答 Voted Best Answer Joe Obbish 2018-08-16T19:55:16+08:002018-08-16T19:55:16+08:00 当工作人员需要等待某种资源时，它会进入服务员名单。没有资源等待逻辑读取。假设您的缓冲池没有调出数据已经在 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 将其 CPU 时间的大约 5% 花费在 上sqlmin!BPool::Get，我认为这与实际执行逻辑读取有关。为了捍卫这个想法，该方法是sqlmin!BUF::AcquireLatch大多数时候调用的方法： 并且在查询期间获取的共享锁存器的数量与逻辑读取的数量大致相同。但这只是一个猜测，因为 Microsoft 没有记录方法名称，而且我不知道“逻辑读取”的完整范围。
当工作人员需要等待某种资源时，它会进入服务员名单。没有资源等待逻辑读取。假设您的缓冲池没有调出数据已经在 SQL Server 管理的内存中。执行大量逻辑读取的查询速度很慢，因为它们会花费大量 CPU 来执行这些逻辑读取。
如果您想了解 SQL Server 在执行逻辑读取时执行的内部操作，那么您可以在运行因逻辑读取而成为瓶颈的查询时使用perfview或其他一些工具进行 ETW 跟踪。如果您认为您的工作负载存在内存吞吐量问题，那么 ETW 跟踪可能是一个很好的步骤。请注意，情况可能并非如此，以下演示几乎可以肯定是处理查询性能问题的错误方法。
首先，我将拼凑一个查询，我希望它花费大部分时间进行逻辑读取：
SQL Server 在整个查询执行过程中使用了一个完整的 CPU 核心。以下是从 10 秒样本中获取的 perfview 结果：
也许圈出的方法名称是您感兴趣的。对于此查询，SQL Server 将其 CPU 时间的大约 5% 花费在 上
sqlmin!BPool::Get，我认为这与实际执行逻辑读取有关。为了捍卫这个想法，该方法是sqlmin!BUF::AcquireLatch大多数时候调用的方法：并且在查询期间获取的共享锁存器的数量与逻辑读取的数量大致相同。但这只是一个猜测，因为 Microsoft 没有记录方法名称，而且我不知道“逻辑读取”的完整范围。