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