【问题标题】:Physical reads with column-store more than that in a heap列存储的物理读取多于堆中的物理读取
【发布时间】:2015-04-03 18:04:11
【问题描述】:

下面是解释我的表格和情况的链接:

Why does the presence of primary key on the table significantly enhance the performance of column-store indexes?

比较两种情况,一种是使用列存储索引运行查询,另一种是在简单堆上运行查询。当我比较这两个结果时,我观察到即使使用列存储的查询比另一种情况执行得更好,但只是在堆上运行。 但是,使用列存储索引的查询涉及物理读取 (1),而原始读取则没有。

两个查询具有相同的执行计划。此外,我在暖缓冲区和冷缓冲区中都运行查询。在冷缓冲区中,原始查询需要 4 次物理读取,而在警告缓冲区中,它需要 0 次物理读取。 但是,使用列存储索引的查询行为保持不变。这背后有什么特别的原因吗?

【问题讨论】:

  • 请参阅"Should questions include “tags” in their titles?",其中的共识是“不,他们不应该”!
  • @AndreasNiedermair - 感谢您编辑它。我的错,我错过了。
  • 不用担心 - 没问题 :)
  • 我观察到类似的事情。即使有空间缓存整个索引,SQL Server 有时也无法充分利用缓存内存来缓存列存储索引。我不知道这是什么原因,我认为这是一个错误。很难复制。例如,当服务器重新启动时消失。

标签: sql-server database-indexes columnstore


【解决方案1】:

SQL Server 2012 发生了很多变化,包括新的 DMV、新的内存管理和添加的 COLUMNSTORE 索引。

问题:使用列存储索引进行查询会导致物理读取(数据缓存未命中)。

假设:SQL Server 2012,聚集列存储索引

免责声明:这不是一个答案,而是进一步讨论的尝试。

列存储(SQL Server 2012 中的新功能)缓存列存储索引对象(压缩),并且此内存与缓冲池分开。

SQL Server 2012 中的内存分配被 SQLOS 中新的任意页分配器简化了,取代了单页 8 KB 和多页分配器(用于大于 8 KB 的请求)。

缓冲池和列存储缓存都通过任意页分配器分配内存。但是,缓冲池缓存数据页,列存储缓存压缩的列存储索引对象。

数据缓存未命中的一个可能解释是列存储内存分配对缓冲池的内存压力可能导致“页面刷新”。

我使用SQL Server 2012 internals一书作为参考。另外,这篇文章解释了 SQL Server 2012 中 COLOMNSTORE 索引是如何使用内存的: Clustered Columnstore Indexes – part 38 (“Memory Structures”)

【讨论】:

  • 很好的答案!感谢您的解释和文章。
猜你喜欢
  • 1970-01-01
  • 2015-05-29
  • 1970-01-01
  • 2020-05-18
  • 2013-04-09
  • 2017-09-30
  • 2012-12-25
  • 2017-08-17
相关资源
最近更新 更多