SQL Serverf 索引 - 索引壓縮 、附加特性 <第十篇>
一、索引壓縮
數據和索引壓縮在SQL Server2008被引入。壓縮一個索引意味著將在一個頁面中獲得更多的關鍵字信息。這可以造成重大的性能改進，因為存儲索引需要的頁面和索引級別更少。因為索引中的鍵值被壓縮和解壓縮，也將造成CPU和內存的開銷，所以這並不是適合所有索引的方案。
默認情況下，索引將不會被壓縮。必須明確地在創建索引時要求索引被壓縮。有兩種壓縮類型：行級壓縮和頁面級壓縮。索引中的非葉子頁面不接受頁面類型壓縮。
創建壓縮索引的語法如下：
CREATE NONCLUSTERED INDEX IX_Person_Name ON PersonOneMillion(Name) WITH(DATA_COMPRESSION = Page)
下面以一個示例來看看壓縮索引的作用：
正常索引：
行級壓縮索引：
頁面級壓縮索引：
我們看到對於100萬索引的Name列索引，索引數據頁面分別是：
| 普通索引 | 行索引 | 頁面索引 |
| 3109 | 2135 | 1962 |
從上面的例子我們可以得出結論，的確壓縮能夠能夠大幅減少索引的頁面量。但是舉個很簡單的例子，如果一臺數據庫服務器上，內存和CPU已是瓶頸，那麽壓縮數據作用實際上並不大。
至於更具體的哪個更好，這個有時間了再慢慢測試。現在只是知道了索引可以壓縮已減少索引數據頁面數量。
附上一個查看索引消息的SQL語句：
--查看索引數據頁數 SELECT i.name,i.type_desc,s.page_count,s.record_count,s.index_level,compressed_page_count FROM sys.indexes i JOIN sys.dm_db_index_physical_stats(DB_ID(N‘DataExample‘),OBJECT_ID(N‘PersonOneMillion‘),NULL,NULL,‘DETAILED‘) AS s ON i.index_id = s.index_id WHERE i.OBJECT_ID = OBJECT_ID(N‘PersonOneMillion‘)
二、 附加特性
1、不同的列排序順序
SQL Server支持使用不同的排序順序為索引的不同列創建一個復雜的索引。如果希望一個索引的第一列按照升序排列二第二列按照降序排列，可以用如下語句完成：
CREATE NONCLUSTERED INDEX IX ON Table(c1 ASC,c2 DESC)
2、BIT數據類型列上的索引
SQL Server允許創建在BIT數據類型列上的索引。創建BIT數據類型列上的索引的能力本身不是一個大的優點，因為這樣的列只能有兩個不同的值。這麽低的選擇性的列通常不是好的索引後選擇。但是，這個功能在考慮覆蓋索引時非常有用。因為覆蓋索引需要包含所有搜索中的返回列，而在索引中添加BIT數據類型列將使得覆蓋索引在需要時包含這樣的列。
3、CREATE INDEX語句也會使用索引提升速度
CREATE INDEX操作被集成到查詢處理器。優化器可能使用已有的索引來減少掃描開銷並在創建索引時排序。
在第一個索引中由於已經包含了Name列，而第二個索引也要使用Name列的時候，創建索引SQL Server直接使用索引掃描的方式來創建索引。
4、並行索引創建
SQL Server支持CREATE INDEX語句的並行計劃，正如在其他SQL查詢中一樣。在一個多處理器的機器上，索引創建不限於單個處理器而是從多個處理器中獲益。可以使用SQL Server的max degree of parallelism配置參數來控制用於CREATE INDEX語句中的處理器數量。這個參數的默認值為0，0表示可以使用任意的CPU數量。
EXEC sp_configure ‘max degree of parallelism‘ --默認值為0 EXEC sp_configure ‘max degree of parallelism‘, 2 --使用2個CPU RECONFIGURE WITH OVERRIDE
這個配置設置立即生效，不需要重啟服務器。
查詢提示MAXDOP可以用於CREATE INDEX語句。而且，CREATE INDEX特性只可以用於SQL Server 2005和2008企業版。
SQL Serverf 索引 - 索引壓縮 、附加特性 <第十篇>