1.为什么索引有助于更快的获取信息，它的工作原理是什么？
2.为什么不推荐使用唯一索引，而是建议使用主键约束或唯一约束？
3.为什么聚集索引比非聚集索引有更快的访问速度？
4.create index 是显示的创建非聚集索引吗？
5.create nonclustred index 创建的是也非聚集索引吗？希望大家回答的时候，尽可能的说的通俗点
2.为什么不推荐使用唯一索引，而是建议使用主键约束或唯一约束？
3.为什么聚集索引比非聚集索引有更快的访问速度？
4.create index 是显示的创建非聚集索引吗？
5.create nonclustred index 创建的是也非聚集索引吗？希望大家回答的时候，尽可能的说的通俗点
解决方案 »
- sql server2000新建组后无法注册,提示:[SQL-DMO]需要使用sql 2005管理工具
- SQL Server 2005里有没有代理？
- 求达人解惑
- SQL 2005 触发器同时检查抬头表和项目表
- 求SQL server 2000 自动增量、完全备份。。。
- 重复数据只显示一条，推荐的产品排在前面（至多排8条），一个SQL问题，大神看看，用distinct爆卡，也不知道改怎么索引处理了
- 请问用语句使字符串'JHA00000024'自动变为'JHA00000025'？
- 一个困惑的查询误语句
- 介绍一本纯sql的书。
- 高手帮忙问个问题啊！关于触发器
- 怎么分析TRC文件？
- Sql server2000像其他开发工具一样提示关键字的功能 给点思路
http://blog.sina.com.cn/s/blog_3d2d79aa0100a0ut.html
所要资料.肯定不会一页一页去找吧,目录好比索引
2.
3.聚集索引为物理存储顺序,也就是说,字典是按a-b-c-...这样排序,如果你要找a开头的字段只要饭到a
大概这里的位子就可以找到所要字段咯
4.默认是非聚集索引
5.非聚集索引
2:哪的推荐?唯一索引与主键或约束生成的默认索引的内部结构和优化器选择没区别。区别在于你的数据库设计方面。
3:数据的物理存储结构是按照聚集索引键来排序的，所以一个表只能有一个聚集索引。但至于是否就快还是分场合。在高选择性下用非聚集索引也是有优势的。
4:如果不指定CLUSTERED所建的索引为nonclustred
5:是的
103 陆君
105 匡明
107 王丽
108 曾华
109 王芳
101 李军如果我查询sno=101，那么就是全表查询，查到第6行就查到了101
现在我为sno创建一个索引索引sno 指针地址
101 6
103 1
105 2
107 3
108 4
109 5我还是查询101，那么第一行就是
可以理解成创建索引就是排序吗？
索引数据独立存储,按索引规则或算法存储数据
2.为什么不推荐使用唯一索引，而是建议使用主键约束或唯一约束？
唯一索引可以存在NULL值
3.为什么聚集索引比非聚集索引有更快的访问速度？
聚集索引:按物理地址存储数据
非聚集索引:链式存储
4.create index 是显示的创建非聚集索引吗？
不一定
5.create nonclustred index 创建的是也非聚集索引吗？
不太清楚?
聚集索引一、索引块与数据块的区别大家都知道，索引可以提高检索效率，因为它的二叉树结构以及占用空间小，所以访问速度块。让我们来算一道数学题：如果表中的一条记录在磁盘上占用1000 字节的话，我们对其中10字节的一个字段建立索引，那么该记录对应的索引块的大小只有10字节。我们知道，SQL Server的最小空间分配单元是“页（Page）”，一个页在磁盘上占用8K空间，那么这一个页可以存储上述记录8条，但可以存储索引800条。现在我们要从一个有8000条记录的表中检索符合某个条件的记录，如果没有索引的话，我们可能需要遍历8000条×1000字节/8K字节=1000个页面才能够找到结果。如果在检索字段上有上述索引的话，那么我们可以在8000条×10字节/8K字节=10个页面中就检索到满足条件的索引块，然后根据索引块上的指针逐一找到结果数据块，这样IO访问量要少的多。二、索引优化技术是不是有索引就一定检索的快呢？答案是否。有些时候用索引还不如不用索引快。比如说我们要检索上述表中的所有记录，如果不用索引，需要访问8000条 ×1000 字节/8K字节=1000个页面，如果使用索引的话，首先检索索引，访问8000条×10字节/8K字节=10个页面得到索引检索结果，再根据索引检索结果去对应数据页面，由于是检索所有数据，所以需要再访问8000条×1000字节/8K字节=1000个页面将全部数据读取出来，一共访问了1010个页面，这显然不如不用索引快。SQL Server内部有一套完整的数据检索优化技术，在上述情况下，SQL Server的查询计划（Search Plan）会自动使用表扫描的方式检索数据而不会使用任何索引。那么SQL Server是怎么知道什么时候用索引，什么时候不用索引的呢？SQL Server除了日常维护数据信息外，还维护着数据统计信息，下图是数据库属性页面的一个截图：
聚簇索引与非聚簇索引的本质区别到底是什么？什么时候用聚簇索引，什么时候用非聚簇索引？这是一个很复杂的问题，很难用三言两语说清楚。我在这里从SQL Server索引优化查询的角度简单谈谈(如果对这方面感兴趣的话，可以读一读微软出版的《Microsoft SQL Server 2000数据库编程》第3单元的数据结构引论以及第6、13、14单元)。
从图中我们可以看到，SQL Server自动维护统计信息，这些统计信息包括数据密度信息以及数据分布信息，这些信息帮助SQL Server决定如何制定查询计划以及查询是是否使用索引以及使用什么样的索引（这里就不再解释它们到底如何帮助SQL Server建立查询计划的了）。我们还是来做个实验。建立一张表：tabTest(ID, unqValue，intValue)，其中ID是整形自动编号主索引，unqValue是uniqueidentifier类型，在上面建立普通索引，intValue 是整形，不建立索引。之所以挂上一个没有索引的intValue字段，就是防止SQL Server使用索引覆盖查询优化技术，这样实验就起不到作用了。向表中录入10000条随机记录，代码如下：
CREATE TABLE [dbo].[tabTest] ([ID] [int] IDENTITY (1, 1) NOT NULL ,[unqValue] [uniqueidentifier] NOT NULL ,[intValue] [int] NOT NULL) ON [PRIMARY]GOALTER TABLE [dbo].[tabTest] WITH NOCHECK ADDCONSTRAINT [PK_tabTest] PRIMARY KEY CLUSTERED([ID]) ON [PRIMARY]GOALTER TABLE [dbo].[tabTest] ADDCONSTRAINT [DF_tabTest_unqValue] DEFAULT (newid()) FOR [unqValue]GOCREATE INDEX [IX_tabTest_unqValue] ON [dbo].[tabTest]([unqValue]) ON [PRIMARY]GOdeclare @i intdeclare @v intset @i=0while @i<10000beginset @v=rand()*1000 insert into tabTest ([intValue]) values (@v)set @i=@i+1end
然后我们执行两个查询并查看执行计划http://www.cnblogs.com/flystone/
Heap译成汉语叫做“堆”，其本义暗含杂乱无章、无序的意思，前面提到数据值被写进数据页时，由于每一行记录之间并没有特定的排列顺序，所以行与行的顺序就是随机无序的，当然表中的数据页也就是无序的了，而表中所有数据页就形成了“堆”。可以说，一张没有索引的数据表，就像一个只有书柜而没有索引卡片柜的图书馆，书库里面塞满了一堆乱七八糟的图书。当读者对管理员提交查询请求后，管理员就一头钻进书库，对照查找内容从头开始一架一柜的逐本查找。运气好的话，在第一个书架的第一本书就 找到了，运气不好的话，要到最后一个书架的最后一本书才找到。
SQLS在接到查询请求时，首先会分析sysindexes表中一个叫做索引标志符(INDID: Index ID)的字段的值，如果该值为0，表示这是一张数据表而不是索引表，SQLS就会使用sysindexes表的另一个字段——也就是在前面提到过的FirstIAM值中找到该表的IAM页链，也就是所有数据页集合。
这就是对一个没有建立索引的数据表进行数据查找的方式，是不是很没效率？对于没有索引的表，对于一“堆”这样的记录，SQLS也只能这样做，而且更没劲的是，即使在第一行就找到了被查询的记录，SQLS仍然要从头到尾的将表扫描一次。这种查询称为“遍历”，又叫“表扫描”。
可见没有建立索引的数据表照样可以运行，不过这种方法对于小规模的表来说没有什么太大的问题，但要查询海量的数据效率就太低了。 （二）SQLS如何访问建立了非聚集索引的数据表
如前所述，非聚集索引可以建多个，具有B树结构，其叶级节点不包含数据页，只包含索引行。假定一个表中只有非聚集索引，则每个索引行包含了非聚集索引键值以及行定位符（ROW ID,RID），他们指向具有该键值的数据行，每一个RID由文件ID、页编号和在页中行的编号组成。
当INDID的值在2至250之间时，意味着表中存在非聚集索引页。此时，SQLS调用ROOT字段的值指向非聚集索引B树的ROOT，在其中查找与被查询最相近的值，根据这个值找到在非叶级节点中的页号，然后顺藤摸瓜，在叶级节点相应的页面中找到该值的RID，最后根据这个RID在Heap中定位所在的页和行并返回到查询端。
例如：假定在Lastname上建立了非聚集索引，则执行Select * From Member Where Lastname=’Ota’时，查询过程是：
①SQLS查询INDID值为2；
②立即从根出发，在非叶级节点中定位最接近Ota的值“Martin”，并查到其位于叶级页面的第61页；
③仅在叶级页面的第61页的Martin下搜寻Ota的RID，其RID显示为N∶706∶4，表示Lastname字段中名 为Ota的记录位于堆的第706页的第4行，N表示文件的ID值，与数据无关；
④根据上述信息，SQLS立刻在堆的第706页第4行将该记录“揪”出来并显示于前台（客户端）。视表的数据量大小，整个查询过程费时从百分之几毫秒到数毫秒不等。
在谈到索引基本概念的时候，我们就提到了这种方式：图书馆的前台有很多索引卡片柜，里面分了若干的类别，诸如按照书名笔画或拼音顺序、作者笔画或拼音顺序等，但有两点不同之处：
① 索引卡片上记录了每本书摆放的具体位置——位于某柜某架的第几本——而不是“特殊编号”；
② 书脊上并没有那个“特殊编号”。管理员在索引柜中查到所需图书的具体位置（RID）后，根据RID直接在书库中的具体位置将书提出来。
显然，这种查询方式效率很高，但资源占用极大，因为书库中书的位置随时在发生变化，必然要求管理员花费额外的精力和时间随时做好索引更新。 （三）SQLS如何访问建立聚集索引的数据表
在聚集索引中，数据所在的数据页是叶级，索引数据所在的索引页是非叶级。
查询原理和上述对非聚集索引的查询相似，但由于记录是按照聚集索引中索引键值进行排序，换句话说，聚集索引的索引键值也就是具体的数据页。
这就好比书库中的书就是按照书名的拼音在排序，而且也只按照这一种排序方式建立相应的索引卡片，于是查询起来要比上述只建立非聚集索引的方式要简单得多。仍以上面的查询为例：
假定在Lastname字段上建立了聚集索引，则执行Select * From Member Where Lastname=’Ota’时，查询过程是：
①SQLS查询INDID值为1，这是在系统中只建立了聚集索引的标志；
②立即从根出发，在非叶级节点中定位最接近Ota的值“Martin”，并查到其位于叶级页面的第120页；
③在位于叶级页面第120页的Martin下搜寻到Ota条目，而这一条目已是数据记录本身；
④将该记录返回客户端。
这一次的效率比第二种方法更高，以致于看起来更美，然而它最大的优点也恰好是它最大的缺点——由于同一张表中同时只能按照一种顺序排列，所以在任何一种数据表中的聚集索引只能建立一个；并且建立聚集索引需要至少相当于源表120%的附加空间，以存放源表的副本和索引中间页。
难道鱼和熊掌就不能兼顾了吗？办法是有的。 （四）SQLS如何访问既有聚集索引、又有非聚集索引的数据表
如果我们在建立非聚集索引之前先建立了聚集索引的话，那么非聚集索引就可以使用聚集索引的关键字进行检索。就像在图书馆中，前台卡片柜中可以有不同类别的图书索引卡，然而每张卡片上都载明了那个特殊编号——并不是书籍存放的具体位置。这样在最大程度上既照顾了数据检索的快捷性，又使索引的日常维护变得更加可行，这是最为科学的检索方法。
也就是说，在只建立了非聚集索引的情况下，每个叶级节点指明了记录的行定位符（RID）；而在既有聚集索引又有非聚集索引的情况下，每个叶级节点所指向的是该聚集索引的索引键值，即数据记录本身。
假设聚集索引建立在Lastname上，而非聚集索引建立在Firstname上，当执行Select * From Member Where Firstname=’Mike’时，查询过程是：
①SQLS查询INDID值为2；
②立即从根出发，在Firstname的非聚集索引的非叶级节点中定位最接近Mike的值“Jose”条目；
③从Jose条目下的叶级页面中查到Mike逻辑位置——不是RID而是聚集索引的指针；
④根据这一指针所指示位置，直接进入位于Lastname的聚集索引中的叶级页面中到达Mike数据记录本身；
⑤将该记录返回客户端。
这就完全和我们在“索引的基本概念”中讲到的现实场景完全一样了，当数据发生更新的时候，SQLS只负责对聚集索引的键值加以维护，而不必考虑非聚集索引。只要我们在ID类的字段上建立聚集索引，而在其它经常需要查询的字段上建立非聚集索引，通过这种科学的、有针对性的在一张表上分别建立聚集索引和非聚集索引的方法，我们既享受了索引带来的灵活与快捷，又相对避免了维护索引所导致的大量的额外资源消耗。 索引的优点和不足
索引有一些先天不足
1、系统要占用大约为表的1.2倍的硬盘和内存空间来保存索引；
2、更新数据的时候，系统必须要有额外的时间来同时对索引进行更新，以维持数据和索引的一致性。
当然建立索引的优点也是显而易见的，在海量数据的情况下，如果合理的建立了索引，则会大大加强SQLS执行查询、对结果进行排序、分组的操作效率。
实践表明，不恰当的索引不但于事无补，反而会降低系统性能。因为大量的索引在进行插入、修改和删除操作时比没有索引要花费更多的系统时间。
在如下字段建立索引应该是不恰当的：
1、很少或从不引用的字段；
2、逻辑型的字段，如男或女(是或否)等。
综上所述，提高查询效率是以消耗一定的系统资源为代价的，索引不能盲目的建立，必须要有统筹的规划，一定要在“加快查询速度”与“降低修改速度”之间做好平衡。有得必有失，此消则彼长，这是考验一个DBA是否优秀的很重要的指标 建立索引时一定要在“加快查询速度”与“降低修改速度”之间做好平衡，有得必有失，此消则彼长。那么，SQLS维护索引时究竟怎样消耗资源？应该从哪些方面对索引进行管理与优化？以下从六个方面来回答这些问题。 一．页分裂 微软MOC教导我们：当一个数据页达到了8K容量，如果此时发生插入或更新数据的操作，将导致页的分裂(又名页拆分)： 1．有聚集索引的情况下：聚集索引将被插入和更新的行指向特定的页，该页由聚集索引关键字决定； 2．只有堆的情况下：只要有空间就可以插入新的行，但是如果我们对行数据的更新需要更多的空间，以致大于当前页的可用空间，行就被移到新的页中，并且在原位置留下一个转发指针，指向被移动的新行，如果具有转发指针的行又被移动了，那么原来的指针将重新指向新的位置； 3．如果堆中有非聚集索引，那么尽管插入和更新操作在堆中不会发生页分裂，但是在非聚集索引上仍然产生页分裂。 无论有无索引，大约一半的数据将保留在老页面，而另一半将放入新页面，并且新页面可能被分配到任何可用的页。所以，频繁页分裂，后果很严重，将使物理表产生大量数据碎片，导致直接造成I/O效率的急剧下降，最后，不得不停止SQLS的运行并重建索引。 二．填充因子 然而在“混沌之初”，就可以在一定程度上避免不愉快出现，在创建索引时，可以为这个索引指定一个填充因子，以便在索引的每个叶级页面上保留一定百分比的空间，将来数据可以进行扩充和减少页分裂。填充因子是从0到100的百分比数值，设为100时表示将数据页填满，只有当不会对数据进行更改时(例如只读表中)才用此设置。值越小则数据页上的空闲空间越大，这样可以减少在索引增长过程中进行页分裂的需要，但这一操作需要占用更多的硬盘空间。 填充因子只在创建索引时执行，索引创建以后，当表中进行数据的添加、删除或更新时，是不会保持填充因子的，如果想在数据页上保持额外的空间，则有悖于使用填充因子的本意，因为随着数据的输入，SQLS必须在每个页上进行页拆分，以保持填充因子指定的空闲空间。因此，只有在表中的数据进行了较大的变动，才可以填充数据页的空闲空间。这时，可以从容的重建索引，重新指定填充因子，重新分布数据。 反之，填充因子指定不当，就会降低数据库的读取性能，其降低量与填充因子设置值成反比。例如，当填充因子的值为50时，数据库的读取性能会降低两倍。所以，只有在表中根据现有数据创建新索引，并且可以预见将来会对这些数据进行哪些更改时，设置填充因子才有意义。 三．两道数学题 假定数据库设计没有问题，那么是否像上篇分析的那样，当你建立了众多的索引，在查询工作中SQLS就只能按照“最高指示”用索引处理每一个提交的查询呢？答案是否定的。
实际上，SQLS几乎完全是“自主”的决定是否使用索引或使用哪一个索引。
这是怎么回事呢？ 让我们先来算一道题：如果某表的一条记录在磁盘上占用1000字节(1K)的话，我们对其中10字节的一个字段建立索引，那么该记录对应的索引大小只有10字节(0.01K)。上篇说过，SQLS的最小空间分配单元是“页（Page）”，一个页面在磁盘上占用8K空间，所以一页只能存储8条“记录”，但可以存储800条“索引”。现在我们要从一个有8000条记录的表中检索符合某个条件的记录(有Where子句)，如果没有索引的话，我们需要遍历8000条×1000字节/8K字节=1000个页面才能够找到结果。如果在检索字段上有上述索引的话，那么我们可以在8000条×10字节/8K字节=10个页面中就检索到满足条件的索引块，然后根据索引块上的指针逐一找到结果数据块，这样I/O访问量肯定要少得多。 然而有时用索引比不用索引还快。 同上，如果要无条件检索全部记录(不用Where子句)，不用索引的话，需要访问8000条×1000字节/8K字节=1000个页面；而使用索引的话，首先检索索引，访问8000条×10字节/8K字节=10个页面得到索引检索结果，再根据索引检索结果去对应数据页面，由于是检索全部数据，所以需要再访问8000条×1000字节/8K字节=1000个页面将全部数据读取出来，一共访问了1010个页面，这显然不如不用索引快。 SQLS内部有一套完整的数据索引优化技术，在上述情况下，SQLS会自动使用表扫描的方式检索数据而不会使用任何索引。那么SQLS是怎么知道什么时候用索引，什么时候不用索引的呢？因为SQLS除了维护数据信息外，还维护着数据统计信息。 四．统计信息 打开企业管理器，单击“Database”节点，右击Northwind数据库→单击“属性”→选择“Options”选项卡，观察“Settings”下的各项复选项，你发现了什么？ 从Settings中我们可以看到，在数据库中，SQLS将默认的自动创建和更新统计信息，这些统计信息包括数据密度和分布信息，正是它们帮助SQLS确定最佳的查询策略：建立查询计划和是否使用索引以及使用什么样的索引。 在创建索引时，SQLS会创建分布数据页来存放有关索引的两种统计信息：分布表和密度表。查询优化器使用这些统计信息估算使用该索引进行查询的成本(Cost)，并在此基础上判断该索引对某个特定查询是否有用。 随着表中的数据发生变化，SQLS自动定期更新这些统计信息。采样是在各个数据页上随机进行。从磁盘读取一个数据页后，该数据页上的所有行都被用来更新统计信息。统计信息更新的频率取决于字段或索引中的数据量以及数据更改量。比如，对于有一万条记录的表，当1000个索引键值发生改变时，该表的统计信息便可能需要更新，因为1000 个值在该表中占了10%，这是一个很大的比例。而对于有1千万条记录的表来说，1000个索引值发生更改的意义则可以忽略不计，因此统计信息就不会自动更新。 五．索引的人工维护 上面讲到,某些不合适的索引将影响到SQLS的性能,随着应用系统的运行,数据不断地发生变化,当数据变化达到某一个程度时将会影响到索引的使用。这时需要用户自己来维护索引。 随着数据行的插入、删除和数据页的分裂，有些索引页可能只包含几页数据，另外应用在执行大量I/O的时候，重建非聚聚集索引可以维护I/O的效率。重建索引实质上是重新组织B树。需要重建索引的情况有： 1．数据和使用模式大幅度变化； 2．排序的顺序发生改变； 3．要进行大量插入操作或已经完成； 4．使用I/O查询的磁盘读次数比预料的要多； 5．由于大量数据修改，使得数据页和索引页没有充分使用而导致空间的使用超出估算； 6．dbcc检查出索引有问题。
DBCC DBREINDEX重建索引提高SQL Server性能 大多数SQL Server表需要索引来提高数据的访问速度，如果没有索引，SQL Server 要进行表格扫描读取表中的每一个记录才能找到索要的数据。索引可以分为簇索引和非簇索引，簇索引通过重排表中的数据来提高数据的访问速度，而非簇索引则通过维护表中的数据指针来提高数据的索引。 1. 索引的体系结构 为什么要不断的维护表的索引？首先，简单介绍一下索引的体系结构。SQL Server在硬盘中用8KB页面在数据库文件内存放数据。缺省情况下这些页面及其包含的数据是无组织的。为了使混乱变为有序，就要生成索引。生成索引后，就有了索引页和数据页，数据页保存用户写入的数据信息。索引页存放用于检索列的数据值清单（关键字）和索引表中该值所在纪录的地址指针。索引分为簇索引和非簇索引，簇索引实质上是将表中的数据排序，就好像是字典的索引目录。非簇索引不对数据排序，它只保存了数据的指针地址。向一个带簇索引的表中插入数据，当数据页达到100%时，由于页面没有空间插入新的的纪录，这时就会发生分页，SQL Server 将大约一半的数据从满页中移到空页中，从而生成两个半的满页。这样就有大量的数据空间。簇索引是双向链表，在每一页的头部保存了前一页、后一页地址以及分页后数据移动的地址，由于新页可能在数据库文件中的任何地方，因此页面的链接不一定指向磁盘的下一个物理页，链接可能指向了另一个区域，这就形成了分块，从而减慢了系统的速度。对于带簇索引和非簇索引的表来说，非簇索引的关键字是指向簇索引的，而不是指向数据页的本身。 为了克服数据分块带来的负面影响，需要重构表的索引，这是非常费时的，因此只能在需要时进行。可以通过DBCC SHOWCONTIG来确定是否需要重构表的索引。 2. DBCC SHOWCONTIG用法 下面举例来说明DBCC SHOWCONTIG和DBCC REDBINDEX的使用方法。以应用程序中的Employee数据表作为例子，在 SQL Server的Query analyzer输入命令： use database_name declare @table_id int set @table_id=object_id('Employee') dbcc showcontig(@table_id) 输出结果： DBCC SHOWCONTIG scanning 'Employee' table... Table: 'Employee' (1195151303); index ID: 1, database ID: 53 TABLE level scan performed. - Pages Scanned................................: 179 - Extents Scanned..............................: 24 - Extent Switches..............................: 24 - Avg. Pages per Extent........................: 7.5 - Scan Density [Best Count:Actual Count].......: 92.00% [23:25] - Logical Scan Fragmentation ..................: 0.56% - Extent Scan Fragmentation ...................: 12.50% - Avg. Bytes Free per Page.....................: 552.3 - Avg. Page Density (full).....................: 93.18% DBCC execution completed. If DBCC printed error messages, contact your system administrator. 通过分析这些结果可以知道该表的索引是否需要重构。如下描述了每一行的意义： 信息 描述 Pages Scanned 表或索引中的长页数 Extents Scanned 表或索引中的长区页数 Extent Switches DBCC遍历页时从一个区域到另一个区域的次数 Avg. Pages per Extent 相关区域中的页数 Scan Density[Best Count:Actual Count] Best Count是连续链接时的理想区域改变数，Actual Count是实际区域改变数，Scan Density为100%表示没有分块。 Logical Scan Fragmentation 扫描索引页中失序页的百分比 Extent Scan Fragmentation 不实际相邻和包含链路中所有链接页的区域数 Avg. Bytes Free per Page 扫描页面中平均自由字节数 Avg. Page Density (full) 平均页密度，表示页有多满 从上面命令的执行结果可以看的出来，Best count为23 而Actual Count为25这表明orders表有分块需要重构表索引。下面通过DBCC DBREINDEX来重构表的簇索引。
sql 帮助上有说：
提示 尽管唯一索引有助于找到信息，但为了获得最佳性能，建议使用主键约束或唯一约束。有关这些约束的更多信息，请参见主键约束和唯一约束。
有点晕了
create index index_sname on student(sname)
create nonclustered index index_sex on student(sex)
用sp_help 可以看出，创建的都是非聚集索引index_sex nonclustered located on PRIMARY sex
index_sname nonclustered located on PRIMARY sname