即使在 Disabling Read-Ahead 和 clearing buffer 之后，为什么还有 Logical Read？

Question

当所有数据页都应仅在磁盘中时，我必须找到在 SQL-SERVER 2016 中执行查询所需的总时间。为此，我使用以下命令清除了 SQL-SERVER 中的所有缓冲区：

DBCC FREEPROCCACHE WITH NO_INFOMSGS
GO
DBCC DROPCLEANBUFFERS
GO
DBCC FREESESSIONCACHE
GO
DBCC FREESYSTEMCACHE ('ALL') WITH MARK_IN_USE_FOR_REMOVAL
GO 
DBCC FLUSHPROCINDB (@dbId)
GO

在此之后，我再次发现存在逻辑读取，然后我了解了 Read-Ahead ，因此我通过跟踪标志禁用了预读

DBCC TRACEON(652,-1)
GO

以及预取标志

DBCC TRACEON(8744,-1)
GO

现在我仍然有逻辑读取，但物理读取明显高于清除缓冲区。有什么办法可以实现0逻辑读，还是我对逻辑读的理解有误？

请指导我，我是 SQL-SERVER 世界的新手

Answer 1

在查询执行期间从缓冲区缓存中检索单个页面时，将计算逻辑读取。无论是使用物理还是预读来缓存页面，或者该页面是否已存在于缓冲区缓存中，这都会被计算在内。因此，逻辑读取是衡量在查询执行期间页面在内存中实际接触的次数的一种度量。

当存储引擎从存储中读取一个或多个页面时，将计算物理读取，因为请求的页面尚未在缓存中。这不包括预读扫描完成的物理 IO。

甲预读的读时，存储引擎期间顺序扫描读取从存储一个或多个完整盘区（每个区是8个连续页）进行计数。预读会积极地将数据预取到内存中，以便在查询需要时页面可能已经被缓存。预读扫描读取的区数因 SQL Server 版本和版本以及碎片而异。我已经看到在使用最新 SQL Server 版本的企业版扫描期间，使用单个分散-聚集 IO 一次读取多达 4MB 的预读扫描。

请注意，SQL Server存储引擎对冷缓存的行为有所不同（例如，在重新启动或 之后DBCC DROPCLEANBUFFERS）。当缓存尚未预热时（满足缓冲区管理器的目标页面），存储引擎执行完整的 64K 区读取而不是单个 8K 页面读取以将页面读入缓存。这比以其他方式发生的情况更快地加热缓存。

出于查询和索引调整的目的，我更喜欢关注逻辑读取而不是物理读取，因为这是对查询执行的工作的更好衡量。数据是否被缓存只是偶然的。恕我直言，使用冷缓存进行测试更多地是衡量存储性能而不是查询性能，并不代表在使用热缓存的生产工作负载下会发生什么。

Answer 2

总会有逻辑读取。SQL Server 永远不会直接从磁盘向您返回数据。如果您需要的页面已经在缓冲池中，则存在逻辑读取。如果不是，则将其移动到缓冲池中，然后还有逻辑读取。您将始终从缓存中读取。

另外，我不明白你测试的意义。仅仅是末日分析吗？如果您只是在从空缓存开始时测量返回数据的时间，为什么不只是测量时间？你为什么担心逻辑/物理读取？如果您不相信您发出的命令清除了计划缓存/缓冲池，您可以在发出查询之前通过 DMV 检查这些内容。