漫游测试之性能测试(5.3-索引分析)

11.1.自动索引分析

优点：数据库引擎调整顾问，是用来分析已有索引的有效性并且为SQL的索引建立提供参考意见。

缺点：只能针对查询语句起作用。

步骤一：启动数据库引擎调整顾问

步骤二：设置配置选项

步骤三：自动分析中

步骤四：生成的建议

11.1.索引理论

11.1.1什么是索引

类似词典查找，词典是按照字母顺序排列的一个不同单词的列表，数据被排序，但是仍然可能存在重复，通常称之为聚集索引。

类似书籍查找，以不同的关键字所对应的页数那样进行排列，通常称之为非聚集索引。

堆表，以行标识符作为指向存储位置的指针，这中间没有数据顺序，也不能进行搜索，只能逐行遍历数据来进行查找，这一过程被定义为扫描。

11.1.2.优化器默认的最佳数据访问机制

11.1.3.判断某列是否适合索引的Sql

select COUNT (DISTINCT 待查看的列名) as "重复的行数",

COUNT (待查看的列名) as "所有的行数",

(CAST ( Count(Distinct 待查看的列名) as DECIMAL ) / CAST(Count(待查看的列名) as DECIMAL )) as "索引选择率"

from 待查看的表名

11.1.4.聚簇索引与非聚簇索引的使用原则

聚簇索引：

a、在创建任何非聚簇索引键之前应建立聚簇索引。

b、聚簇索引总体长度应最小，故应考虑窄索引。

c、检索一定范围的数据使用聚簇索引。

d、读取预先排序的数据，使用聚簇索引[即order by 的字段]。

何时不使用聚簇索引：

频繁更新的列。

聚簇索引频繁更新，将导致所有非聚簇索引的行定位器相应更新，从而显著增加相关查询的开销，并将阻塞这段时间引用相同部分的非聚簇索引的其它查询，从而影响数据库的并行性。

宽的关键字。
太多并行的顺序插入。

非聚簇索引：

非聚簇索引在需要从一个大表上读取少量的行时最有效。
频繁更新的列更适合非聚簇索引。
宽的关键字的列更适合非聚簇索引。

11.1.5. 非聚簇索引－－覆盖索引

覆盖索引是在所有为满足SQL查询不用到达基本表所需的列上建立的非聚簇索引。如果查询遇到一个索引并且完全不需要引用底层数据表，那么该索引可以被认为是覆盖索引。[不懂]

覆盖索引对减少查询的逻辑读次数是一种有用的技术。覆盖索引对请求一定范围的行、或者排序输出的查询能够得到比聚簇索引更好的性能。

create nonclustered index [IX_覆盖索引的名字] on 表名 (字段 desc/asc) include (字段)

覆盖索引能够帮助解决阻塞和死锁的问题。

11.1.6. 非聚簇索引－－过滤索引

过滤索引是使用过滤器的非聚簇索引，这个过滤器基本上是一个Where子句，用来在可能没有很好选择性的一个或多个列上创建一个高选择性的关键字组。例如，一个具有大量null值的列可能被存储为稀疏列来降低这些null值的开销，在这个列添加一个过滤索引将使你拥有在不是null的数据上的索引。

create nonclustered index [IX_覆盖索引的名字] on 表名 (字段 desc/asc) include (字段) where 条件

11.1.7. 丢失索引的SQL语法

待补充

11.1.8. 书签查找的定义

查询所引用的其他行不在非聚簇索引中，要读取这些列的值，必须通过聚簇索引从非聚簇索引行导航到对应的数据行，这个操作就是一个书签查找。如果查询的各部分（不只是选择列表）中引用的列不都包含在使用的非聚簇索引中，就会发生书签查找操作。

缺点：书签查找增加了查询逻辑读操作的次数。并且如果页面不在内存中，书签查找可能需要在磁盘上的一个随机I/O操作来从索引页面跳转到数据页面，还需要必需的CPU能力来汇集这一数据并执行必要的操作。这一特性使得书签查找的数据检索操作的开销相当的大。这个开销因素是非聚簇索引更适合于返回较小的行集的原因。随着查询检索的行数的增加，书签查找的开销将变得无法接受。

关键字查询－〉右键－〉Output List property(输出列表属性)-〉单击省略号，就可以查看到“不在非聚簇索引中的所需列”的内容。

11.1.9. 书签查找的解决方法

a)、使用一个聚簇索引

即将当前引用到的列改为聚簇索引。

b)、使用一个覆盖索引

b.1将查询引用中的其它列添加到非聚簇索引中，构建成一个覆盖索引。

b.2另一个达到覆盖索引的方法不需要添加关键字列，而是使用包含列，如下所示：

create unique nonclustered index [索引名称] on 列名 (字段) include (其它字段) with drop_existing

c)、使用索引连接

11.2.0. 索引列上的统计应保持自动更新

索引的有效性完全取决于索引列的统计，没有统计，Sql Server基于开销的查询优化器不能决定使用一个索引的最有效方式，为了符合这一要求，Sql Server自动创建索引键的统计，不管索引是何时建立的。

查看自动统计是否开启：

属性－〉选项－〉数据库自动更新统计设置（ Auto Update Statistics setting of a database ）

关闭/开启自动更新统计功能：

alter database 数据库名 set auto_update_statistics off/on

11.2.1. 索引碎片分析查看的手段

当插入或者更新表中的数据时，表的对应聚簇索引和受影响的聚簇索引被修改，如果对索引的修改不能容纳于同一页面中（即8KB页），可能导致索引叶子页面分割。一个新的叶子页面将被添加以包含原来页面的部分，并且维持索引键中行的逻辑顺序，虽然新的叶子页面维护原始页面中行的逻辑顺序，但是这个新的页面通常在磁盘上不与原来页面相邻。

内部碎片和外部碎片对数据检索性能都有负面的影响。外部碎片导致磁盘上的索引页面不连续，新的叶子页面和原始叶子页面离得很远，物理顺序与逻辑顺序不同。

可以使用以下SQL进行查询：

select s.avg_fragmentation_in_percent as '表示索引和堆的逻辑平均碎片百分比' ,

s.fragment_count as '碎片的数量',

s.page_count as '组成统计的索引或数据页面数量的计数',

s.avg_page_space_used_in_percent as '索引页面中分配的空间量',

s.record_count as '统计代表的记录数',

avg_record_size_in_bytes as '在索引或堆记录中存储的数据量'

from sys.dm_db_index_physical_stats (DB_ID('数据库'),OBJECT_ID(N'表名'),null,null,'Sampled') as s

s.avg_fragmentation_in_percent：

1.平均碎片小于10-20%，碎片不成问题。

2.碎片在20-40%，碎片可能成为问题，但是可以通过索引重组来消除索引碎片。

3.碎片>40%，需要索引重建。

11.2.2. 自动化维护索引碎片

１.确定当前数据库中所有需要分析碎片的用户表。

２.确定所有用户表和索引的碎片。

３.考虑以下因素以确定需要进行碎片整理的用户表和索引。

　高的碎片水平－－avg_fragmentation_in_percent大于%

　不是非常小的表/索引－－也就是page_count大于的

脚本解释：

１.遍历系统上所有数据库并确认符合碎片条件的每个数据库中用户表上的索引，并将它们保存到一个临时表中。

２.根据碎片水平，重新整理碎片较少的索引并重建碎片很多的索引。

/* 执行存储过程*/

use AdventureWorks

execute IndexDefrag

create procedure IndexDefrag as

declare @DBName nvarchar(255),

@TableName nvarchar(255),

@SchemaName nvarchar(255),

@IndexName nvarchar(255),

@PctFrag DECIMAL

DECLARE @Defrag nvarchar(max)

if exists(select * from sys.objects where object_id =object_id (N'#Frag'))

Drop Table #Frag

create table #Frag

( DBName nvarchar(255),

TableName nvarchar(255),

SchemaName nvarchar(255),

IndexName nvarchar(255),

AvgFragment DECIMAL)

exec sp_MSforeachdb 'insert into #Frag(

DBName,

TableName,

SchemaName,

IndexName,

AvgFragment

) select ''?'' as DBName,

t.Name as TableName,

sc.Name as SchemaName,

i.name as IndexName,

s.avg_fragmentation_in_percent

from ?.sys.dm_db_index_physical_stats(DB_ID(''?''),null,null,null,''Sampled'') as s

join ?.sys.indexes i

on s.Object_Id=i.Object_id

and s.Index_Id=i.Index_id

join ?.sys.tables t

on i.Object_id=t.Object_id

join ?.sys.schemas sc

on t.schema_id=sc.SCHEMA_ID

where s.avg_fragmentation_in_percent>20

and t.TYPE=''U''

and s.page_count>8

order by TableName,IndexName '

declare cList Cursor for select * from #Frag

open cList

FETCH NEXT From cList

into @DBName,@TableName,@SchemaName,@IndexName,@PctFrag

while @@FETCH_STATUS =0

BEGIN

if @PctFrag Between 20.0 and 40.0 –-比例可以自己调整

begin

set @Defrag=N'ALTER INDEX '+@IndexName +' ON '+@DBName +'.' +@SchemaName +'.'+@TableName +' REORGANIZE '

exec sp_executesql @Defrag

PRINT '该索引碎片率在%~40%之间，修改索引：Reorganize index:'+@DBName+'.'+@SchemaName+'.'+@TableName+'.'+@IndexName

END

ELSE if @PctFrag >40.0 –-比例可以自己调整

begin

set @Defrag=N'ALTER INDEX ' +@IndexName+' ON '+@DBName +'.'+@SchemaName +'.'+@TableName +' REBUILD '

EXEC sp_executesql @Defrag

Print '该索引碎片率在大于%之间，重建索引：Reuild index:'+@DBName +'.'+@SchemaName+'.'+@TableName+'.'+@IndexName

End

FETCH Next from cList

into @DBName,@TableName,@SchemaName,@IndexName,@PctFrag

End

Close cList

DEALLOCATE cList

Drop Table #Frag