SQL Server 2012 中代号Denali为列存储索引的新功能之一。
我对常规的旧行存储索引了解很多，例如 b-tree 结构、叶级和 b-tree 页面之间的存储差异、包含字段的影响、优化使用它们、键的顺序等。
我很难获得有关列存储索引 内部的任何好的信息。
- 它的结构如何？
- 有b树吗？其他结构到位了吗？
- 数据是如何组织的？
- 什么样的特定运算符最适合使用它？
- 使用它们时要避免的任何其他反模式？
我能找到的很多关于它们的内容基本上与“正常”索引完全相反，即没有键的排序，没有包含的字段，只有非聚集的。
任何见解都值得赞赏。
列存储结构
列存储数据物理存储在每列一个或多个 段（常规 LOB 分配单元）中，也可以按通常的方式进行分区。每个段包含大约一百万行高度压缩的值或值引用（有多种压缩技术可用）。值引用链接到最多两个散列字典之一中的条目。
字典在查询执行期间固定在内存中，每当执行需要实际数据值时，都会在字典中查找来自段的数据值 ID（出于性能原因，此查找会尽可能延迟）。
段还具有包含元数据的标头记录，例如存储在段中的最小值和最大值。来自标头的信息通常可用于在执行时从处理中消除完整的分区。标头记录信息存储在通常的 LOB 数据根结构中，因此消除段意味着存储引擎可以跳过从物理存储中完全读取 LOB 数据页。最大限度地消除消除的可能性可能需要仔细设计，包括在构建列存储索引时对聚集索引顺序的依赖。
特定计划运营商
SQL Server 2012 引入了一种称为批处理模式的新执行模式。在这种模式下，大约 1000 行的数据包在算子之间传递，显着提高了处理器的使用效率。在每个数据包中，柱状数据表示为一个向量。并非所有计划运算符都支持批处理模式操作，但支持的示例包括 Columnstore Index Scan、Hash Inner Join、Batch Hash Table Build、Bitmap Filter、Hash Aggregate（非标量聚合）、Filter 和 Compute Scalar（用于投影和表达式评估）。查询执行计划已得到增强，以显示估计和实际执行模式。
反模式
第一个版本有很多限制，包括对允许的数据类型的限制。支持最常见的类型；不支持的数据类型包括
DECIMAL精度大于 18 位、(N)VARCHAR(MAX)、UNIQUEIDENTIFIER、 CLR 类型和(VAR)BINARY.使用字符串类型,
OUTER JOIN,IN,EXISTS,NOT IN,OR,UNION ALL可能会导致性能显着降低（行模式执行），除非采用通常涉及异常语法重写的变通方法，如本节链接文章中所示。更多信息
Remus Rusanu 在这里发表了一篇很棒的博客文章。