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

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

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

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

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

从压缩的角度来看（主要是游程编码），选择的常见排序顺序可能对某些段很好，但对其他段则不然。SQL Server 使用 Vertipaq 技术来选择能够提供良好整体压缩结果的排序顺序。

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

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

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

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

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

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

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

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

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

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

这样做是有意义的，是的。有时需要通过主键或唯一约束来强制执行业务需求。这两种方法都会在具有聚集列存储索引的表上生成基础索引。

对于某些类型的查询，聚集列存储索引不是一个好的数据结构。可能性能极差的示例包括SQL Server 2016 上的字符串聚合、递归查询和没有相等条件的连接。更一般地，任何需要从表中快速查找少量数据的查询可能无法仅从聚集列存储索引中看到最佳性能。确实，行组消除有时会导致与非聚集索引相似的性能，但这需要按特定顺序加载数据，并且并非所有数据类型都受支持。

在具有聚集列存储索引的表上创建非聚集索引有一些缺点。并行插入不再可用，索引占用额外的存储空间，SQL Server 在某些场景下压缩顺序的选项会减少。

根据我的经验，我发现在考虑将非聚集索引添加到具有聚集列存储索引的表时，最好设置比平时更高的标准。如果您真的需要它，请尝试添加它，但请记住它的缺点。