列存儲

磁盤的每個Page僅僅存儲來自單列的值，而不是整行的值。因此，壓縮算法會更加高效，因為它們能夠作用於同類型的數據。例如，假定我們有一張有3列數據的表，這3列從左往右依次是int、varchar和bool類型，並且該表有100條（行）記錄。對於都是int類型的第一列數據，應用壓縮算法是很容易的，同時壓縮率也會很高。這也將表明，我們不必訪問該表的所有列，僅需訪問感興趣的相關列的子集，這從另一方面來講，可以減少磁盤的I/O、提升緩存利用率，因此，磁盤存儲會被更加高效的利用，就像索引維護一樣。

列存儲適合用在什麼場合?

OLAP，數據倉庫，數據挖掘等查詢密集型應用。當然，列存儲數據庫並不是説完全不能進行更新操作，其實它們的更新操作性能並不是很差，一般也夠用，但是一方面不如自己的查詢性能，另外一方面也不如Oracle這種專門搞OLTP的數據庫，所以一般就不提這個。

列存儲不適合用在什麼場合?

相對來説，不適合用在OLTP，或者更新操作，尤其是插入、刪除操作頻繁的場合。 ^[1] 

分列數據格式：每次對一個列的數據進行分組和存儲。　SQL　Server　查詢處理可以利用新的數據佈局，並顯著改進查詢執行時間。加快查詢結果：列存儲索引由於以下原因而可更快地生成結果：

（1）只須讀取需要的列。因此，從磁盤讀到內存中、然後從內存移到處理器緩存中的數據量減少了。

（2）列經過了高度壓縮。這將減少必須讀取和移動的字節數。

（3）大多數查詢並不會涉及表中的所有列。　因此，許多列從不會進入內存。　這一點與出色的壓縮方法相結合，可改善緩衝池使用率，從而減少總　I/O。

（4）高級查詢執行技術以簡化的方法處理列塊（稱為“批處理”），從而減少　CPU　使用率。

列存儲索引的侷限性

（1）包含的列數不能超過　1024。

（2）無法聚集。　只有非聚集列存儲索引才可用。

（3）不能是唯一索引。

（4）不能基於視圖或索引視圖創建。

（5）不能包含稀疏列。

（6）不能作為主鍵或外鍵。

（7）不能使用　ALTER　INDEX　語句更改。　而應在刪除後重新創建列存儲索引。

（8）不能使用　INCLUDE　關鍵字創建。

（9）不能包括用來對索引排序的　ASC　或　DESC　關鍵字。　根據壓縮算法對列存儲索引排序。　不允許在索引中進行排序。　可能按照搜索算法對從列存儲索引中選擇的值進行排序，但是必須使用　ORDER　BY　子句來確保對結果集進行排序。

（10）不以傳統索引的方式使用或保留統計信息。

（11）無法更新具有列存儲索引的表。

內存受限的影響：列存儲處理針對內存中處理進行了優化。　SQL　Server　實現了若干機制，使得數據或大多數數據結構可以在可用內存不足時溢出到磁盤。　如果存在嚴重的內存限制，則處理過程將使用行存儲。　在某些實例中，可能會選擇列存儲索引作為訪問方法，但內存不足以生成所需數據結構。　通過先以列存儲操作開始，然後默認為一個較慢的代碼路徑，在查詢遇到嚴重內存限制時，可能會導致性能出現一定程度的降低。　任何查詢的有效內存要求取決於特定的查詢。生成列存儲索引要求的內存量大約為：8　MB×索引中的列數×DOP（並行度）。通常，內存要求隨着作為字符串的列的比例提高而增加。　因此，降低　DOP　可以減少生成列存儲索引所需的內存。

一些表達式的計算將比其他表達式更快：當使用列存儲索引時，應使用批處理模計算某些常見表達式，而不以一次一行的模式進行計算。　除了使用列存儲索引所帶來的優勢之外，批處理模式還將提供其他查詢加速效果。　並不為批處理模式處理啓用每個查詢執行運算符。

列存儲索引不支持　SEEK：如果查詢應返回行的一小部分，則優化器不大可能選擇列存儲索引（例如：needle-in-the-haystack　類型查詢）。如果使用表提示　FORCESEEK，則優化器將不考慮列存儲索引。

列存儲索引不能與以下功能結合使用：頁和行壓縮以及　vardecimal　存儲格式（列存儲索引已採用不同格式壓縮），複製，更改跟蹤，變更數據捕獲，文件流。 ^[2] 

SQL　Server　2012所提供的列式索引及其相關查詢功能在技術上取得了突破性的進展，可以為數據倉庫查詢提供空前的性能優勢。企業的最終用户可以使用熟悉的報表工具，在更短的時間內從數據中獲取商業價值，他們將成為最主要的受益者。