SQL Server 2012：性能列存储索引与 B 树答案

【问题标题】：SQL Server 2012: performance columnstore index vs B-treeSQL Server 2012：性能列存储索引与 B 树
【发布时间】：2012-04-12 04:52:16
【问题描述】：

列存储索引的一个好处是单个列的数据“在磁盘上彼此相邻”存储。这代表更好的压缩和更快的读取时间。

但是；当使用 B 树（常规的非聚集索引）时，该树的叶子不是数据本身吗？因此，当我在 A 列上创建索引时，A 列的所有字段不会在磁盘上与表并行排序吗？这意味着数据可以被压缩并且可以快速读取。

简而言之：列存储索引究竟何时比单列上的 B 树更高效？

提前致谢！

【问题讨论】：

标签： sql-server indexing sql-server-2012 b-tree columnstore

【解决方案1】：

所以当我在 A 列上创建索引时，A 列的所有字段都不会出现在磁盘上与表并行排序？

是的，A 列将被排序。但所有其他列都不会。列存储索引按排序顺序存储所有列（以 2^20 行为单位）。

【讨论】：

好的。但是，当您从 A 列中选择某些内容时，无论哪种情况，A 的所有数据都会被排序。那么我可以假设在查询其他列时列存储索引也更有效吗？但是，当我在这些列上也简单地放置一个 B 树时呢？
当您需要对数据进行排序时，B-Tree 根本不需要排序操作（如果您请求的列是索引的前缀）。列存储无法为它们提供排序，因为它按 2^20 行存储它们。如果您有多个此类段，则无法提供排序顺序。
我认为这里可能存在一些误解。列存储索引的目的是（或者我认为），从磁盘读取数据的开销更少，因为只能加载相关的列。从行存储加载时，会获取整个行，因此加载可能不需要的列。现在的情况如下：如果我只对一列感兴趣，比如 A，与简单的 B 树（非聚集索引）相比，列存储索引如何提高性能。非聚集索引的叶子实际上存储为一列，一个又一个字段，尽可能紧凑。
在单个列上，任何一个都可能更有效。如果您一次检索所有内容，列存储将因为压缩和批处理模式而更加高效。如果您在列上进行过滤，B-tree 会变得更有效率。
我可以将此标记为答案 :) 但是，在我看来，列存储索引令人惊叹的情况并不多。正如您所说，在所描述的情况下，B 树更有效。只有索引开销问题会阻止我在所需列上构建 B 树，或将它们包含在另一个索引中（取决于情况和查询）。