索引设计的建议：

一.检查where子句和连接条件列

当一个查询提交到sql server时，查询优化器尝试为查询中引用的所有表查找最佳的数据访问机制，

一下是它所进行的方式。

1.优化器识别Where子句和连接条件中包含的列、

2.接着优化器检查这些列的索引.

3.优化器通过从索引上维护的统计确定子句的选择性(也就是返回多少行),评估每个索引的有效性

4.最终,优化器根据前面几个步骤中收集的信息,评估读取所限定的行开销最低的方法.

 

下面看个例子:  Table_1表内 又 30000条数据

执行查询:

查看结果:

逻辑读取的次数为 95次.

下面加上where  条件句, where 的列 是 含有聚集索引的.

结果:

很明显, 逻辑读 次数减少了两次.

 

下面看 where 条件句,where 的列 不含有索引的:

 

查询的结果:

总结:

where 子句列 帮助 优化器选择 一个对 查询最优的索引操作. 这也使用于 两个表之间的连接条件中使用的列.

优化器 查找在 where子句 或连接条件列上的索引,如果可用,考虑使用该索引 来从表中检索行,查询优化器在执行一个查询时,

考虑where子句或连接条件列上的索引. 因此,在where子句或连接条件中 频繁使用的列上有 索引将 帮助查询优化器避免基本表的扫描.

 

注意:  当一个表中的数据总量非常小以至于可以 放入一个单独的页面(8kb)时,表扫描可能比索引查找工作 得更好,

 

二: 使用 窄索引

应该避免在索引中使用 宽数据类型 的列. 比如 字符串类型(char,varchar,nchar ,nvarchar)的列有时候可能和二进制类型一样大.

窄索引可以再8kb的索引页面中 容纳比 宽索引 更多的行,这将有一下效果:

1.减少 i/o数量 (读取更少的8kb页面)

2.使数据库缓存更有效,因为 sql server 可以缓存更少的索引页面,从而减少内存中的索引页面所需的逻辑读操作.

3.减少数据库的存储空间.

 

下面看个例子:

表a id为主键, 所以 a有个聚集索引, 那么id列的数据类型是 int,a表有数据27行数据,

说明所有的 索引 总大小为 4*27 byte, 一个索引页面(8kb)完全可以容得下.

sys.indexes系统表 在每个数据库中保存,包含了数据库中所有索引的基本信息.

DMF  sys.dm_db_index_physical_stats 包含了关于索引上统计的更详细信息.

下面看sql语句: 

select i.name,i.type_desc,s.page_count,s.record_count,s.index_level  from sys.indexes i  join  sys.dm_db_index_physical_stats(DB_ID(N'test'),OBJECT_ID(N'dbo.a'),null,null,'DETAILED') as s  on i.index_id=s.index_id where i.OBJECT_ID=OBJECT_ID(N'dbo.a')

获取如下 结果:

说明 索引页数 是1页, index_leval =0说明是 聚集索引.

 

下面使用宽索引 的一个例子:

b表结果如下:  name列有一个  非聚集索引,索引名字为: IX_b  由于name 的数据类型为 char(500),b内数据有23行, 说明非聚集索引占用的大小事 23*500byte,那么超出了一个页面的大小,

按照预测,name的索引将存在两个索引页面, 下面用sql语句来证实这个结论.

 

sql语句:

select i.name,i.type_desc,s.page_count,s.record_count,s.index_level  from sys.indexes i  join  sys.dm_db_index_physical_stats(DB_ID(N'test'),OBJECT_ID(N'dbo.b'),null,null,'DETAILED') as s  on i.index_id=s.index_id where i.OBJECT_ID=OBJECT_ID(N'dbo.b')

查询结果如下:

果然,看到 IX_b record_count =23的 行, 它的 page_count是2 ,说明我们之前的猜想是正确的.

 

这就是宽索引的劣势.

三:检查列的唯一性.

在一个具有很小范围的可能值的列(如性别,只有,f和m)上创建索引,对性能是没有很大帮助的.

因为查询优化器不能使用索引有效的减少返回的行. 

考虑只有两个唯一值 的 性别列(F和M).当执行一个 具有使用 性别列的where子句查询时,最终从表中得打很大数量的行,导致开销很大的表,或聚集索引扫描.

结论:

所以 使用where子句中的列 具有 大量的唯一行,一限制访问的行数,是个首选的方案. 应该在 这些列上 创建索引,来帮助 查询优化器

访问小的结果集.

而且,在创建多个列上的索引时(符合索引),列的顺序是有关系的.在某些情况下,先使用最有选择性的列将使索引行的列更有效率.

可以使用下面的语句 来判断 列的选择性.

test1 自己随意定义的表  select count(distinct EventClass) as 不同的值,  count(EventClass) as 多少行,  cast(count(distinct EventClass) as decimal) as 选择性      from test1

结果如下:

具有最高的唯一值数量(或选择性)的列 是 where子句 或连接条件 中引用的索引的 最佳候选.

 

四:考虑索引类型

`sql server主要有两种索引，聚集索引和非聚集索引，这两种类型的索引 都为 B-树 结构。两者之间的主要区别 是

聚集索引的叶子页面 是表的数据页面，因此数据和其指针的顺序相同，这意味着 聚集索引就是该表。

 

下一篇 ，主要讲述这两种索引。