列儲存索引的結構是什麼？
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 在這裡發表了一篇很棒的部落格文章。