向聚集列儲存索引表添加索引是否有意義？
Question is similar to this one，但答案似乎沒有回答這個問題。
我對聚集列儲存表的理解（如果我錯了，請糾正我）是每列都以某種物理有序的方式儲存，這意味著每列已經具有相當於聚集索引的內容。如果是這種情況，那麼在表上添加更多索引就沒有多大意義……或者會嗎？也許是綜合指數？
我的想法對嗎？
我對聚集列儲存表的理解（如果我錯了，請糾正我）是每列都以某種物理有序的方式儲存……
所有列都按相同的順序排序。我這樣說是為了與您的陳述的可能閱讀區分開來，即每列都以該列的最佳方式排序，這是不正確的。
每一列在每一行組內的一個**段中單獨編碼和壓縮。操作順序為：
- 對所有列中的值進行編碼（例如，值偏移量，或使用字典）。
- 確定單個“最佳”行排序。
- 壓縮每一列（例如 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+ 樹慢得多。這項實證研究表明，對於某些工作負載，混合物理設計可以提供顯著的性能提升。
