将索引添加到聚集列存储索引表是否有意义？

Question

问题与this one类似，但答案似乎没有回答这个问题。

我对聚集列存储表的理解（如果我错了，请纠正我）是每列都以某种物理排序的方式存储，这意味着每列已经有相当于聚集索引的内容。如果是这种情况，那么在表上添加更多索引就没有多大意义了……或者是吗？也许是一个综合指数？

我的想法是否正确？

Answer 1

我对聚集列存储表的理解（如果我错了，请纠正我）是每列都以某种物理顺序存储......

所有列都按相同顺序排序。我这样说是为了与您的陈述的可能阅读区分开来，即每一列都以该列的最佳方式排序，这是不正确的。

每列都在每个行组内的一个段中单独编码和压缩。操作顺序为：

1. 对所有列中的值进行编码（例如值偏移，或使用字典）。
2. 确定单个“最佳”行排序。
3. 压缩每一列（例如 RLE、bit-pack）。

选择的通用排序顺序对于某些段可能很好，但从压缩的角度来看（主要是运行长度编码）则不然。SQL Server 使用 Vertipaq 技术选择一种排序顺序，以提供良好的整体压缩结果。

...暗示每列已经有相当于聚集索引的内容

这不是正确的心理图，因为列存储“索引”不支持查找，只有 b 树支持。SQL Server 可以在列存储中定位单个行以进行查找（如链接的问答中所示），但这与一般支持键查找不同。

对聚集列存储索引进行查找的演示。

区别在于在行组 #m 中查找行 #n 与查找具有特定列的给定值“x”的行。列存储索引可以做前者，但不能做后者。

此外，b-tree 索引可以返回有序数据；列存储索引不能（由于编码）——除了最多返回一行的查找的微不足道的情况。

将索引添加到聚集列存储索引表是否有意义？

当我们需要定位单个值或小范围的值时，额外的 b 树索引是有意义的。另一种方法是扫描列存储索引（尽管如果星星正确对齐，则可能会消除行组 - 如果表已分区，则可能会消除分区）。

更一般地，b-tree 索引支持 OLTP 类型的查询；列存储用于分析。在同一张表上提供这两者可以实现混合方法（HTAP - 混合事务/分析处理）。

来自 Microsoft Research Paper Columnstore 和 B+ 树——混合物理设计重要吗？(PDF):

当查询谓词具有选择性时，即使所有数据都驻留在内存中，B+ 树也比列存储更出色；当数据不驻留在内存中时，权衡进一步有利于 B+ 树。同样，当服务器内存受限时，B+ 树可能是按排序顺序提供数据的更好选择。另一方面，无论数据是否驻留在内存中，对于大型扫描，列存储通常要快一个数量级。对于更新，B+ 树要便宜得多。与主列存储索引相比，辅助列存储产生的更新成本要低得多，但仍然比 B+ 树慢得多。这项实证研究表明，对于某些工作负载，混合物理设计可以提供显着的性能提升。