一、索引的概念
索引就是加快检索表中数据的方法。数据库的索引类似于书籍的索引。在书籍中,索引允许用户不必翻阅完整个书就能迅速地找到所需要的信息。在数据库中,索引也允许数据库程序迅速地找到表中的数据,而不必扫描整个数据库。
二、索引的特点
1.索引可以加快数据库的检索速度
2.索引降低了数据库插入、修改、删除等维护任务的速度
3.索引创建在表上,不能创建在视图上
4.索引既可以直接创建,也可以间接创建
5.可以在优化隐藏中,使用索引
6.使用查询处理器执行SQL语句,在一个表上,一次只能使用一个索引
7.其他
三、索引的优点
1.创建唯一性索引,保证数据库表中每一行数据的唯一性
2.大大加快数据的检索速度,这也是创建索引的最主要的原因
3.加速表和表之间的连接,特别是在实现数据的参考完整性方面特别有意义。
4.在使用分组和排序子句进行数据检索时,同样可以显著减少查询中分组和排序的时间。
5.通过使用索引,可以在查询的过程中使用优化隐藏器,提高系统的性能。
四、索引的缺点
1.创建索引和维护索引要耗费时间,这种时间随着数据量的增加而增加
2.索引需要占物理空间,除了数据表占数据空间之外,每一个索引还要占一定的物理空间,如果要建立聚簇索引,那么需要的空间就会更大
3.当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,降低了数据的维护速度
五、索引分类
1.直接创建索引和间接创建索引
直接创建索引: CREATE INDEX mycolumn_index ON mytable (myclumn)
间接创建索引:定义主键约束或者唯一性键约束,可以间接创建索引
2.普通索引和唯一性索引
普通索引:CREATE INDEX mycolumn_index ON mytable (myclumn)
唯一性索引:保证在索引列中的全部数据是唯一的,对聚簇索引和非聚簇索引都可以使用
CREATE UNIQUE COUSTERED INDEX myclumn_cindex ON mytable(mycolumn)
3.单个索引和复合索引
单个索引:即非复合索引
复合索引:又叫组合索引,在索引建立语句中同时包含多个字段名,最多16个字段
CREATE INDEX name_index ON username(firstname,lastname)
4.聚簇索引和非聚簇索引(聚集索引,群集索引)
聚簇索引:物理索引,与基表的物理顺序相同,数据值的顺序总是按照顺序排列
CREATE CLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn) WITH
ALLOW_DUP_ROW(允许有重复记录的聚簇索引)
非聚簇索引:CREATE UNCLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn)
六、索引的使用
1.当字段数据更新频率较低,查询使用频率较高并且存在大量重复值是建议使用聚簇索引
2.经常同时存取多列,且每列都含有重复值可考虑建立组合索引
3.复合索引的前导列一定好控制好,否则无法起到索引的效果。如果查询时前导列不在查询条件中则该复合索引不会被使用。前导列一定是使用最频繁的列
4.多表操作在被实际执行前,查询优化器会根据连接条件,列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表;内外表的选择可由公式:外层表中的匹配行数*内层表中每一次查找的次数确定,乘积最小为最佳方案
5.where子句中对列的任何操作结果都是在sql运行时逐列计算得到的,因此它不得不进行表搜索,而没有使用该列上面的索引;如果这些结果在查询编译时就能得到,那么就可以被sql优化器优化,使用索引,避免表搜索(例:select * from record where substring(card_no,1,4)=’5378’
&& select * from record where card_no like ’5378%’)任何对列的操作都将导致表扫描,它包括数据库函数、计算表达式等等,查询时要尽可能将操作移至等号右边
6.where条件中的’in’在逻辑上相当于’or’,所以语法分析器会将in ('0','1')转化为column='0' or column='1'来执行。我们期望它会根据每个or子句分别查找,再将结果相加,这样可以利用column上的索引;但实际上它却采用了"or策略",即先取出满足每个or子句的行,存入临时数据库的工作表中,再建立唯一索引以去掉重复行,最后从这个临时表中计算结果。因此,实际过程没有利用column上索引,并且完成时间还要受tempdb数据库性能的影响。in、or子句常会使用工作表,使索引失效;如果不产生大量重复值,可以考虑把子句拆开;拆开的子句中应该包含索引
7.要善于使用存储过程,它使sql变得更加灵活和高效
索引使用原则:
1、使用索引来更快地遍历表。
缺省情况下建立的索引是非群集索引,但有时它并不是最佳的。在非群集索引下,数据在物理上随机存放在数据页上。合理的索引设计要建立在
对各种查询的分析和预测上。一般来说:
a.有大量重复值、且经常有范围查询( > ,< ,> =,< =)和order by、group by发生的列,可考
虑建立群集索引;
b.经常同时存取多列,且每列都含有重复值可考虑建立组合索引;
c.组合索引要尽量使关键查询形成索引覆盖,其前导列一定是使用最频繁的列。索引虽有助于提高性能但不是索引越多越好,恰好相反过多的索引会导致系统低效。用户在表中每加进一个索引,维护索引集合就要做相应的更新工作。
2、在海量查询时尽量少用格式转换。
3、ORDER BY和GROPU BY使用ORDER BY和GROUP BY短语,任何一种索引都有助于SELECT的性能提高。
7、任何对列的操作都将导致表扫描,它包括数据库函数、计算表达式等等,查询时要尽可能将操作移至等号右边。
4、IN、OR子句常会使用工作表,使索引失效。如果不产生大量重复值,可以考虑把子句拆开。拆开的子句中应该包含索引。
Sql的优化原则2:
1、只要能满足你的需求,应尽可能使用更小的数据类型:例如使用MEDIUMINT代替INT
2、尽量把所有的列设置为NOT NULL,如果你要保存NULL,手动去设置它,而不是把它设为默认值。
3、尽量少用VARCHAR、TEXT、BLOB类型
4、如果你的数据只有你所知的少量的几个。最好使用ENUM类型
5、正如graymice所讲的那样,建立索引。
以下是我做的一个实验,可以发现索引能极大地提高查询的效率:
我有一个会员信息表users,里边有37365条用户记录:
在不加索引的时候进行查询:
sql语句A:
select * from users where username like ’%许%’;
在Mysql-Front中的8次查询时长为:1.40,0.54,0.54,0.54,0.53,0.55,0.54 共找到960条记录
sql语句B:
select * from users where username like ’许%’;
在Mysql-Front中的8次查询时长为:0.53,0.53,0.53,0.54,0.53,0.53,0.54,0.54 共找到836条记录
sql语句C:
select * from users where username like ’%许’;
在Mysql-Front中的8次查询时长为:0.51,0.51,0.52,0.52,0.51,0.51,0.52,0.51 共找到7条记录
为username列添加索引:
create index usernameindex on users(username(6));
再次查询:
sql语句A:
select * from users where username like ’%许%’;
在Mysql-Front中的8次查询时长为:0.35,0.34,0.34,0.35,0.34,0.34,0.35,0.34 共找到960条记录
sql语句B:
select * from users where username like ’许%’;
在Mysql-Front中的8次查询时长为:0.06,0.07,0.07,0.07,0.07,0.07,0.06,0.06 共找到836条记录
sql语句C:
select * from users where username like ’%许’;
在Mysql-Front中的8次查询时长为:0.32,0.31,0.31,0.32,0.31,0.32,0.31,0.31 共找到7条记录
在实验过程中,我没有另开任何程序,以上的数据说明在单表查询中,建立索引的可以极大地提高查询速度。
另外要说的是如果建立了索引,对于like ’许%’类型的查询,速度提升是最明显的。因此,我们在写sql语句的时候也尽量采用这种方式查询。
对于多表查询我们的优化原则是:
尽量将索引建立在:left join on/right join on ... +条件,的条件语句中所涉及的字段上。
多表查询比单表查询更能体现索引的优势。
6、索引的建立原则:
如果一列的中数据的前缀重复值很少,我们最好就只索引这个前缀。Mysql支持这种索引。我在上面用到的索引方法就是对username最左边的6个字符进行索引。索引越短,占用的
磁盘空间越少,在检索过程中花的时间也越少。这方法可以对最多左255个字符进行索引。
在很多场合,我们可以给建立多列数据建立索引。
索引应该建立在查询条件中进行比较的字段上,而不是建立在我们要找出来并且显示的字段上
7、限制索引的使用的避归。
7.1 IN、OR子句常会使用工作表,使索引失效。
如果不产生大量重复值,可以考虑把子句拆开。拆开的子句中应该包含索引。这句话怎么理解决,请举个例子
例子如下:
如果在fields1和fields2上同时建立了索引,fields1为主索引
以下sql会用到索引
select * from tablename1 where fields1=’value1’ and fields2=’value2’
以下sql不会用到索引
select * from tablename1 where fields1=’value1’ or fields2=’value2’
7.2 使用IS NULL 或IS NOT NULL
使用IS NULL 或IS NOT NULL同样会限制索引的使用。因为NULL值并没有被定义。在SQL语句中使用NULL会有很多的麻烦。因此建议开 发人员在建表时,把需要索引的列设成NOT NULL。如果被索引的列在某些行中存在NULL值,就不会使用这个索引(除非索引是一个位图索引,关于位图索引在稍后在详细讨论)。
7.3 使用函数
如果不使用基于函数的索引,那么在SQL语句的WHERE子句中对存在索引的列使用函数时,会使优化器忽略掉这些索引。下面的查询不会使用索引(只要它不是基于函数的索引)
select empno,ename,deptno
from emp
where trunc(hiredate)='01-MAY-81';
把上面的语句改成下面的语句,这样就可以通过索引进行查找。
select empno,ename,deptno
from emp
where hiredate<(to_date('01-MAY-81')+0.9999);
7.4 比较不匹配的数据类型
比较不匹配的数据类型也是比较难于发现的性能问题之一。注意下面查询的例子,account_number是一个VARCHAR2类型,在account_number字段上有索引。下面的语句将执行全表扫描。
select bank_name,address,city,state,zip
from banks
where account_number = 990354;
Oracle可以自动把where子句变成to_number(account_number)=990354,这样就限制了索引的使用,改成下面的查询就可以使用索引:
select bank_name,address,city,state,zip
from banks
where account_number ='990354';
特别注意:不匹配的数据类型之间比较会让Oracle自动限制索引的使用,即便对这个查询执行Explain Plan也不能让您明白为什么做了一 次“全表扫描”。
补充:
1.索引带来查询上的速度的大大提升,但索引也占用了额外的硬盘空间(当然现在一般硬盘空间不成问题),而且往表中插入新记录时索引也要随着更新这也需要一定时间.
有些表如果经常insert,而较少select,就不用加索引了.不然每次写入数据都要重新改写索引,花费时间;
这个视实际情况而定,通常情况下索引是必需的.
2.我在对查询效率有怀疑的时候,一般是直接用Mysql的Explain来跟踪查询情况.
你用Mysql-Front是通过时长来比较,我觉得如果从查询时扫描字段的次数来比较更精确一
可以利用索引快速访问数据库表中的特定信息。索引是对数据库表中一个或多个列(例如,employee 表的姓氏 (lname) 列)的值进行排序的结构。如果想按特定职员的姓来查找他或她,则与在表中搜索所有的行相比,索引有助于更快地获取信息。
索引提供指针以指向存储在表中指定列的数据值,然后根据指定的排序次序排列这些指针。数据库使用索引的方式与使用书的目录很相似:通过搜索索引找到特定的值,然后跟随指针到达包含该值的行。
在数据库关系图中,可以为选定的表创建、编辑或删除索引/键属性页中的每个索引类型。当保存附加在此索引上的表或包含此表的数据库关系图时,索引同时被保存。有关详细信息,请参见创建索引。
通常情况下,只有当经常查询索引列中的数据时,才需要在表上创建索引。索引将占用磁盘空间,并且降低添加、删除和更新行的速度。不过在多数情况下,索引所带来的数据检索速度的优势大大超过它的不足之处。然而,如果应用程序非常频繁地更新数据,或磁盘空间有限,那么最好限制索引的数量。
(yi)
为什么要创建索引呢?这是因为,创建索引可以大大提高系统的性能。
第一,通过创建唯一性索引,可以保证数据库表中每一行数据的唯一性。
第二,可以大大加快 数据的检索速度,这也是创建索引的最主要的原因。
第三,可以加速表和表之间的连接,特别是在实现数据的参考完整性方面特别有意义。
第四,在使用分组和排序 子句进行数据检索时,同样可以显著减少查询中分组和排序的时间。
第五,通过使用索引,可以在查询的过程中,使用优化隐藏器,提高系统的性能。
也许会有人要问:增加索引有如此多的优点,为什么不对表中的每一个列创建一个索引呢?这种想法固然有其合理性,然而也有其片面性。虽然,索引有许多优点, 但是,为表中的每一个列都增加索引,是非常不明智的。这是因为,增加索引也有许多不利的一个方面。
第一,创建索引和维护索引要耗费时间,这种时间随着数据 量的增加而增加。
第二,索引需要占物理空间,除了数据表占数据空间之外,每一个索引还要占一定的物理空间,如果要建立聚簇索引,那么需要的空间就会更大。
第三,当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,这样就降低了数据的维护速度。
索引是建立在数据库表中的某些列的上面。因此,在创建索引的时候,应该仔细考虑在哪些列上可以创建索引,在哪些列上不能创建索引。一般来说,应该在这些列 上创建索引,例如:
在经常需要搜索的列上,可以加快搜索的速度;
在作为主键的列上,强制该列的唯一性和组织表中数据的排列结构;
在经常用在连接的列上,这 些列主要是一些外键,可以加快连接的速度;
在经常需要根据范围进行搜索的列上创建索引,因为索引已经排序,其指定的范围是连续的;
在经常需要排序的列上创 建索引,因为索引已经排序,这样查询可以利用索引的排序,加快排序查询时间;
在经常使用在WHERE子句中的列上面创建索引,加快条件的判断速度。
同样,对于有些列不应该创建索引。一般来说,不应该创建索引的的这些列具有下列特点:
第一,对于那些在查询中很少使用或者参考的列不应该创建索引。这是因 为,既然这些列很少使用到,因此有索引或者无索引,并不能提高查询速度。相反,由于增加了索引,反而降低了系统的维护速度和增大了空间需求。
第二,对于那 些只有很少数据值的列也不应该增加索引。这是因为,由于这些列的取值很少,例如人事表的性别列,在查询的结果中,结果集的数据行占了表中数据行的很大比 例,即需要在表中搜索的数据行的比例很大。增加索引,并不能明显加快检索速度。
第三,对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为,这些列的数据量要么相当大,要么取值很少。
第四,当修改性能远远大于检索性能时,不应该创建索 引。这是因为,修改性能和检索性能是互相矛盾的。当增加索引时,会提高检索性能,但是会降低修改性能。当减少索引时,会提高修改性能,降低检索性能。因 此,当修改性能远远大于检索性能时,不应该创建索引。
创建索引的方法和索引的特征
创建索引的方法
创建索引有多种方法,这些方法包括直接创建索引的方法和间接创建索引的方法。直接创建索引,例如使用CREATE INDEX语句或者使用创建索引向导,间接创建索引,例如在表中定义主键约束或者唯一性键约束时,同时也创建了索引。虽然,这两种方法都可以创建索引,但是,它们创建索引的具体内容是有区别的。
使用CREATE INDEX语句或者使用创建索引向导来创建索引,这是最基本的索引创建方式,并且这种方法最具有柔性,可以定制创建出符合自己需要的索引。在使用这种方式创建索引时,可以使用许多选项,例如指定数据页的充满度、进行排序、整理统计信息等,这样可以优化索引。使用这种方法,可以指定索引的类型、唯一性和复合性,也就是说,既可以创建聚簇索引,也可以创建非聚簇索引,既可以在一个列上创建索引,也可以在两个或者两个以上的列上创建索引。
通过定义主键约束或者唯一性键约束,也可以间接创建索引。主键约束是一种保持数据完整性的逻辑,它限制表中的记录有相同的主键记录。在创建主键约束时,系统自动创建了一个唯一性的聚簇索引。虽然,在逻辑上,主键约束是一种重要的结构,但是,在物理结构上,与主键约束相对应的结构是唯一性的聚簇索引。换句话说,在物理实现上,不存在主键约束,而只存在唯一性的聚簇索引。同样,在创建唯一性键约束时,也同时创建了索引,这种索引则是唯一性的非聚簇索引。因此,当使用约束创建索引时,索引的类型和特征基本上都已经确定了,由用户定制的余地比较小。
当在表上定义主键或者唯一性键约束时,如果表中已经有了使用CREATE INDEX语句创建的标准索引时,那么主键约束或者唯一性键约束创建的索引覆盖以前创建的标准索引。也就是说,主键约束或者唯一性键约束创建的索引的优先级高于使用CREATE INDEX语句创建的索引。
索引的特征
索引有两个特征,即唯一性索引和复合索引。
唯一性索引保证在索引列中的全部数据是唯一的,不会包含冗余数据。如果表中已经有一个主键约束或者唯一性键约束,那么当创建表或者修改表时,SQL Server自动创建一个唯一性索引。然而,如果必须保证唯一性,那么应该创建主键约束或者唯一性键约束,而不是创建一个唯一性索引。当创建唯一性索引时,应该认真考虑这些规则:当在表中创建主键约束或者唯一性键约束时,SQL Server自动创建一个唯一性索引;如果表中已经包含有数据,那么当创建索引时,SQL Server检查表中已有数据的冗余性;每当使用插入语句插入数据或者使用修改语句修改数据时,SQL Server检查数据的冗余性:如果有冗余值,那么SQL Server取消该语句的执行,并且返回一个错误消息;确保表中的每一行数据都有一个唯一值,这样可以确保每一个实体都可以唯一确认;只能在可以保证实体完整性的列上创建唯一性索引,例如,不能在人事表中的姓名列上创建唯一性索引,因为人们可以有相同的姓名。
复合索引就是一个索引创建在两个列或者多个列上。在搜索时,当两个或者多个列作为一个关键值时,最好在这些列上创建复合索引。当创建复合索引时,应该考虑这些规则:最多可以把16个列合并成一个单独的复合索引,构成复合索引的列的总长度不能超过900字节,也就是说复合列的长度不能太长;在复合索引中,所有的列必须来自同一个表中,不能跨表建立复合列;在复合索引中,列的排列顺序是非常重要的,因此要认真排列列的顺序,原则上,应该首先定义最唯一的列,例如在(COL1,COL2)上的索引与在(COL2,COL1)上的索引是不相同的,因为两个索引的列的顺序不同;为了使查询优化器使用复合索引,查询语句中的WHERE子句必须参考复合索引中第一个列;当表中有多个关键列时,复合索引是非常有用的;使用复合索引可以提高查询性能,减少在一个表中所创建的索引数量。
(er)
能。使用这些语句可以更好地调整查询和索引。SHOWPLAN语句显示在连接表中使用的查询优化器的每一步以及表明使用哪一个索引访问数据。使用SHOWPLAN语句可以查看指定查询的查询规划。当使用SHOWPLAN语句时,应该考虑这些因素。SET SHOWPLAN_ALL语句返回的输出结果比SET SHOWPLAN_TEXT语句返回的输出结果详细。然而,应用程序必须能够处理SET SHOWPLAN_ALL语句返回的输出结果。SHOWPLAN语句生成的信息只能针对一个会话。如果重新连接SQL Server,那么必须重新执行SHOWPLAN语句。STATISTICS IO语句表明输入输出的数量,这些输入输出用来返回结果集和显示指定查询的逻辑的和物理的I/O的信息。可以使用这些信息来确定是否应该重写查询语句或者重新设计索引。使用STATISTICS IO语句可以查看用来处理指定查询的I/O信息。
就象SHOWPLAN语句一样,优化器隐藏也用来调整查询性能。优化器隐藏可以对查询性能提供较小的改进,并且如果索引策略发生了改变,那么这种优化器隐藏就毫无用处了。因此,限制使用优化器隐藏,这是因为优化器隐藏更有效率和更有柔性。当使用优化器隐藏时,考虑这些规则:指定索引名称、当 index_id为0时为使用表扫描、当index_id为1时为使用聚簇索引;优化器隐藏覆盖查询优化器,如果数据或者环境发生了变化,那么必须修改优化器隐藏。
(san)
索引调整向导
索引调整向导是一种工具,可以分析一系列数据库的查询语句,提供使用一系列数据库索引的建议,优化整个查询语句的性能。对于查询语句,需要指定下列内容:
查询语句,这是将要优化的工作量
包含了这些表的数据库,在这些表中,可以创建索引,提高查询性能
在分析中使用的表
在分析中,考虑的约束条件,例如索引可以使用的最大磁盘空间
这里指的工作量,可以来自两个方面:使用SQL Server捕捉的轨迹和包含了SQL语句的文件。索引调整向导总是基于一个已经定义好的工作量。如果一个工作量不能反映正常的操作,那么它建议使用的索引不是实际的工作量上性能最好的索引。索引调整向导调用查询分析器,使用所有可能的组合评定在这个工作量中每一个查询语句的性能。然后,建议在整个工作量上可以提高整个查询语句的性能的索引。如果没有供索引调整向导来分析的工作量,那么可以使用图解器立即创建它。一旦决定跟踪一条正常数据库活动的描述样本,向导能够分析这种工作量和推荐能够提高数据库工作性能的索引配置。
索引调整向导对工作量进行分析之后,可以查看到一系列的报告,还可以使该向导立即创建所建议的最佳索引,或者使这项工作成为一种可以调度的作业,或者生成一个包含创建这些索引的SQL语句的文件。
索引调整向导允许为SQL Server数据库选择和创建一种理想的索引组合和统计,而不要求对数据库结构、工作量或者SQL Server内部达到专家的理解程度。总之,索引调整向导能够作到以下几个方面的工作:
通过使用查询优化器来分析工作量中的查询任务,向有大量工作量的数据库推荐一种最佳的索引混合方式
分析按照建议作出改变之后的效果,包括索引的用法、表间查询的分布和大量工作中查询的工作效果
为少量查询任务推荐调整数据库的方法
通过设定高级选项如磁盘空间约束、最大的查询语句数量和每个索引的最多列的数量等,允许定制推荐方式
图解器
图解器能够实时抓取在服务器中运行的连续图片,可以选取希望监测的项目和事件,包括Transact-SQL语句和批命令、对象的用法、锁定、安全事件和错误。图解器能够过滤这些事件,仅仅显示用户关心的问题。可以使用同一台服务器或者其他服务器重复已经记录的跟踪事件,重新执行那些已经作了记录的命令。通过集中处理这些事件,就能够很容易监测和调试SQL Server中出现的问题。通过对特定事件的研究,监测和调试SQL Server问题变得简单多了。
查询处理器
查询处理器是一种可以完成许多工作的多用途的工具。在查询处理器中,可以交互式地输入和执行各种Transact-SQL语句,并且在一个窗口中可以同时查看Transact-SQL语句和其结果集;可以在查询处理器中同时执行多个Transact-SQL语句,也可以执行脚本文件中的部分语句;提供了一种图形化分析查询语句执行规划的方法,可以报告由查询处理器选择的数据检索方法,并且可以根据查询规划调整查询语句的执行,提出执行可以提高性能的优化索引建议,这种建议只是针对一条查询语句的索引建议,只能提高这一条查询语句的查询性能。
系统为每一个索引创建一个分布页,统计信息就是指存储在分布页上的某一个表中的一个或者多个索引的关键值的分布信息。当执行查询语句时,为了提高查询速度和性能,系统可以使用这些分布信息来确定使用表的哪一个索引。查询处理器就是依赖于这些分布的统计信息,来生成查询语句的执行规划。执行规划的优化程度依赖于这些分布统计信息的准确步骤的高低程度。如果这些分布的统计信息与索引的物理信息非常一致,那么查询处理器可以生成优化程度很高的执行规划。相反,如果这些统计信息与索引的实际存储的信息相差比较大,那么查询处理器生成的执行规划的优化程度则比较低。
查询处理器从统计信息中提取索引关键字的分布信息,除了用户可以手工执行UPDATE STATISTICS之外,查询处理器还可以自动收集统计这些分布信息。这样,就能够充分保证查询处理器使用最新的统计信息,保证执行规划具有很高的优化程度,减少了维护的需要。当然,使用查询处理器生成的执行规划,也有一些限制。例如,使用执行规划只能提高单个查询语句的性能,但是可能对整个系统的性能产生正面的或者付面的影响,因此,要想提高整个系统的查询性能,应该使用索引调整向导这样的工具。
结论
在以前的SQL Server版本中,在一个查询语句中,一个表上最多使用一个索引。而在SQL Server 7.0中,索引操作得到了增强。SQL Server现在使用索引插入和索引联合算法来实现在一个查询语句中的可以使用多个索引。共享的行标识符用于连接同一个表上的两个索引。如果某个表中有一个聚簇索引,因此有一个聚簇键,那么该表上的全部非聚簇索引的叶节点使用该聚簇键作为行定位器,而不是使用物理记录标识符。如果表中没有聚簇索引,那么非聚簇索引继续使用物理记录标识符指向数据页。在上面的两种情况中,行定位器是非常稳定的。当聚簇索引的叶节点分开时,由于行定位器是有效的,所以非聚簇索引不需要被修改。如果表中没有聚簇索引,那么页的分开就不会发生。而在以前的版本中,非聚簇索引使用物理记录标识符如页号和行号,作为行的定位器。例如,如果聚簇索引(数据页)发生分解时,许多记录行被移动到了一个新的数据页,因此有了多个新的物理记录标识符。那么,所有的非聚簇索引都必须使用这些新的物理记录标识符进行修改,这样就需要耗费大量的时间和资源。
索引调整向导无论对熟练用户还是新用户,都是一个很好的工具。熟练用户可以使用该向导创建一个基本的索引配置,然后在基本的索引配置上面进行调整和定制。新用户可以使用该向导快速地创建优化的索引。
(0