【问题标题】:SQL Server high logical reads vs scan countSQL Server 高逻辑读取与扫描计数
【发布时间】:2015-02-07 16:12:19
【问题描述】:

从性能调优的角度来看,哪个更重要?

假设一个查询报告了一个包含大约 200 万条记录的表的 30 次扫描和 148 次逻辑读取。

同一查询的修改版本报告了 1 次扫描和 1400 次逻辑读取。第二个查询执行的 CPU 时间减少了大约 40 毫秒。第二个查询更好吗?

我认为是这样,这是我的论文:

在第一种情况下,我们对一个非常大的表进行了大量扫描。这对 CPU 和服务器内存的开销很大,因为表中的所有行都必须加载到内存中。执行这样的查询数千次将消耗服务器资源。

在第二种情况下,即使我们累积了更多的逻辑读取,我们的扫描也更少。由于逻辑读取有效地对应于从缓存中读取的页面数量,因此这里的瓶颈将是网络带宽,将结果返回给客户端。在这种情况下,SQL Server 要做的实际工作更少。

你有什么想法?

【问题讨论】:

  • Stack overflow 是一个问答网站,因此这个问题不合适,因为它可能会产生基于辩论和意见的答案。
  • 确保在运行查询之前执行DBCC DOPCLEANBUFFERS,以便使用冷缓冲区缓存测试查询。否则,物理计数扫描的结果会产生误导。
  • @GB,我不认为这是一场辩论。当然有一种推荐的方法来进行数据库优化,这就是我正在寻找的。​​span>

标签: sql-server tsql query-performance


【解决方案1】:

逻辑读取指标大多无关紧要。您关心经过的时间、花费的 CPU 时间和使用的磁盘资源。为什么要关心逻辑读取?它们是通过查看 CPU 时间来计算的。

如果您希望查询速度更快,请测量挂钟时间。如果您想使用更少的资源,请测量 CPU 和物理 IO。

【讨论】:

  • 我担心逻辑读取的唯一原因是因为我们的服务操作引起了我们的注意,一些查询会产生数十亿的逻辑读取并请求优化查询。我们认为我们有更多的性能查询。执行计划更简单,CPU 时间更少,但在一张表上,逻辑读取更多。因此,在提出解决方案作为修复之前,我们需要说服自己逻辑读取与性能无关。
  • 那你需要找出任何高逻辑读的问题。是具体的。我不知道有任何这样的问题。逻辑读取计入 CPU 时间指标。
猜你喜欢
  • 2018-08-02
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-01-02
  • 1970-01-01
  • 1970-01-01
  • 2015-02-28
  • 2018-01-15
相关资源
最近更新 更多