SQL Serverf 索引 - 索引壓縮 、附加特性 <第十篇>

1、索引壓縮

　　數據和索引壓縮在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')

2、 附加特性

　　一、不一樣的列排序順序

　　SQL Server支持使用不一樣的排序順序爲索引的不一樣列建立一個複雜的索引。若是但願一個索引的第一列按照升序排列二第二列按照降序排列，能夠用以下語句完成：

　　CREATE NONCLUSTERED INDEX IX ON Table(c1 ASC,c2 DESC)

　　二、BIT數據類型列上的索引

　　SQL Server容許建立在BIT數據類型列上的索引。建立BIT數據類型列上的索引的能力自己不是一個大的優勢，由於這樣的列只能有兩個不一樣的值。這麼低的選擇性的列一般不是好的索引後選擇。可是，這個功能在考慮覆蓋索引時很是有用。由於覆蓋索引須要包含全部搜索中的返回列，而在索引中添加BIT數據類型列將使得覆蓋索引在須要時包含這樣的列。

　　三、CREATE INDEX語句也會使用索引提高速度

　　CREATE INDEX操做被集成到查詢處理器。優化器可能使用已有的索引來減小掃描開銷並在建立索引時排序。

　　

　　在第一個索引中因爲已經包含了Name列，而第二個索引也要使用Name列的時候，建立索引SQL Server直接使用索引掃描的方式來建立索引。

　　四、並行索引建立

　　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企業版。