SQLServer索引调优实践(2) 索引覆盖
继续SQLServer索引调优实践。这次探讨一下索引覆盖 - SQL Server主要使用索引去查询你需要的数据，当索引包括所有的你请求查询的字段，SQL Server将不需要去在表中查询。这个概念称做“索引覆盖”。
SQLServer2005的Non-clustered INDEX增加了一个“包含列(included column)
”选项。在 SQL Server 2005
中，可以通过将非键列添加到非聚集索引的叶级别来扩展非聚集索引的功能。通过包含非键列，可以创建覆盖更多查询的非聚集索引。当查询中的所有列都作为键列
或非键列包含在索引中时，带有包含性非键列的索引可以显著提高查询性能。这样可以实现性能提升，因为查询优化器可以在索引中找到所有列值；不访问表或聚集
索引数据，从而减少磁盘 I/O 操作。
但应避免添加不必要的列。添加过多的索引列（键列或非键列）会对性能产生不良影响，应该合理使用。和Clustered
INDEX，或者组合索引，结合使用，扩大索引覆盖，但不大可能所有列都有索引覆盖，磁盘开销和数据insert
updat时索引的重新计算的时间开销是巨大的。总之，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引与程序结合起来,才能产生最
佳的优化方案。
继续实践，先建个实验表 Table1：
建两个索引：
1. 主键ID是Clustered INDEX
2. 非聚簇索引Non-Clustered INDEX建立在Age列上，包含列：Count。
CREATE NONCLUSTERED INDEX [cnt] ON [dbo].[table1]
(
[Age] ASC
)
INCLUDE ( [Count])
ON [PRIMARY]
我们的测试SQL语句是：从10万条记录中取出4条记录，两种写法
1. SELECT *
from table1 WHERE age < 100;
2. SELECT count
from table1 WHERE age < 100;
看看运行效率如何：
磁盘IO和时间：
实际执行计划：
性能居然相差20多倍。为什么？
原来第二句Select Count
在索引覆盖范围内，因为查询优化器可以在索引中找到所有列值；不访问表或聚集索引数据，从而减少磁盘 I/O 操作。而第一句Select *
选择了所有字段，其中有一个字段Name不在索引覆盖范围内（既不在聚簇索引列，也不在非聚簇索引覆盖列内），SQL
Server可以在同一个查询中为一个表使用多个索引，并可以合并多个索引（使用联接算法），以便搜索关键字共同覆盖一个查询。查询分析优化器会自动进行
选择, 上述执行计划就是优化的结果，依然比第二个index seek慢了20倍。
然后我又把sql改了一下，变成从10万条
相关文档：
create database DB
use DB
--专业表
create table major
(spno char(5) not null primary key,
spname varchar(20) not null,
pno char(2) )
--学生表
create table student
(sno char(7) not null primary key,
sname varchar(20) not null,
ssex char(2) not null,
sag ......
DATEDIFF(datepart, startdate, enddate)
Datepart Abbreviations
year yy, yyyy
quarter qq, q
month mm, m
......
索引的重要性
数据库性能优化中索引绝对是一个重量级的因素，可以说，索引使用不当，其它优化措施将毫无意义。
聚簇索引
(Clustered Index)和非聚簇索引
(Non- Clustered Index)
最通俗的解释是:聚簇索引的顺序就是数据的物理存储顺序，而对非聚簇索引的索引顺序与数据物理排列顺序无关。举例来说，你翻到新华字典的� ......
