[转]你真的了解SQL的索引吗（索引原理篇）你真的了解SQL的索引吗（索引原理篇）2010-12-18第三：访问创建有聚集

[转]你真的了解SQL的索引吗（索引原理篇）
你真的了解SQL的索引吗（索引原理篇）

2010-12-18

第三：访问创建有聚集索引的表。

聚集索引中，数据所在的数据页是叶级，索引数据所在的索引页是非叶级。原理和上述非聚集索引的查询差不多，由于记录是按聚集索引键值进行排序，即聚集索引的索引键值也就是具体的数据页。这种情况比起非聚集索引要简单很多,因为比非聚集索引少了一层节点查询。

上篇文章的username字段上建立了聚集索引，此时执行Select* From student Where username='1'时，查询过程是：

第四：怎样访问既有聚集索引、又有非聚集索引的数据表：

username字段上建立了聚集索引，cityid上建立了非聚集索引，当执行Select * From student Where cityid='0101'时，查询过程是：

在sysindexes表查询INDID值为2,说明有非聚集索引；从根出发，在cityid的非聚集索引的非叶级节点中定位最接近0101的条目；从上面条目下的叶级页面中查到0101的逻辑位置，是聚集索引的指针；根据指针所指示位置，进入位于username的聚集索引中的叶级页面中找到0101数据记录；将该记录返回客户端。

通过上面数据库访问索引的原理，我们就很容易解释聚集索引与非聚集索引的区别了，原理都一样，关键看什么场合应用什么索引了,下一篇我来总结一些不同场合最适合采用什么样的索引，不对之外多多指点。

二、索引优化技术

是不是有索引就一定检索的快呢？答案是否。有些时候用索引还不如不用索引快。比如说我们要检索上述表中的所有记录，如果不用索引，需要访问8000条×1000 字节/8K字节=1000个页面，如果使用索引的话，首先检索索引，访问8000条×10字节/8K字节=10个页面得到索引检索结果，再根据索引检索结果去对应数据页面，由于是检索所有数据，所以需要再访问8000条×1000字节/8K字节=1000个页面将全部数据读取出来，一共访问了1010个页面，这显然不如不用索引快。

三、聚簇索引与非聚簇索引的本质区别

现在可以讨论聚簇索引与非聚簇索引的本质区别了。正如本文最前面的两个图所示，聚簇索引的叶节点就是数据节点，而非聚簇索引的页节点仍然是索引检点，并保留一个链接指向对应数据块。

还是通过一道数学题来看看它们的区别吧：假设有一8000条记录的表，表中每条记录在磁盘上占用1000字节，如果在一个10字节长的字段上建立非聚簇索引主键，需要二叉树节点16000个（这16000个节点中有8000个叶节点，每个页节点都指向一个数据记录），这样数据将占用8000条×1000字节 /8K字节=1000个页面；索引将占用16000个节点×10字节/8K字节=20个页面，共计1020个页面。

同样一张表，如果我们在对应字段上建立聚簇索引主键，由于聚簇索引的页节点就是数据节点，所以索引节点仅有8000个，占用10个页面，数据仍然占有1000个页面。

下面我们看看在执行插入操作时，非聚簇索引的主键为什么比聚簇索引主键要快。主键约束要求主键不能出现重复，那么SQL Server是怎么知道不出现重复的呢？唯一的方法就是检索。对于非聚簇索引，只需要检索20个页面中的16000个节点就知道是否有重复，因为所有主键键值在这16000个索引节点中都包含了。但对于聚簇索引，索引节点仅仅包含了8000个中间节点，至于会不会出现重复必须检索另外8000个页数据节点才知道，那么相当于检索10+1000=1010个页面才知道是否有重复。所以聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多。

让我们再来看看数据检索的效率，如果对上述两表进行检索，在使用索引的情况下（有些时候SQL Server执行计划会选择不使用索引，不过我们这里姑且假设一定使用索引），对于聚簇索引检索，我们可能会访问10个索引页面外加1000个数据页面得到结果（实际情况要比这个好），而对于非聚簇索引，系统会从20个页面中找到符合条件的节点，再映射到1000个数据页面上（这也是最糟糕的情况），比较一下，一个访问了1010个页面而另一个访问了1020个页面，可见检索效率差异并不是很大。所以不管非聚簇索引也好还是聚簇索引也好，都适合排序，聚簇索引仅仅比非聚簇索引快一点。

结语

关于聚簇索引与非聚簇索引效率问题的实验就不做了，感兴趣的话可以自己使用查询分析器对查询计划进行分析。SQL Server是一个很复杂的系统，尤其是索引以及查询优化技术，Oracle就更复杂了。了解索引以及查询背后的事情不是什么坏事，它可以帮助我们更为深刻的了解我们的系统。

-------------------------------------

非聚簇对于更新肯定是有优势的
而它在检索的性能损失也不会太大

所以能不用聚簇当然是最好的了
但是如果使用\order by的话　
聚簇的优势也应该是很明显的

-------------------------------------

?? 索引有两种类型：聚簇索引和非聚簇索引。

在聚簇索引中，索引树的叶级页包含实际的数据：记录的索引顺序与物理顺序相同。
在非聚簇索引中，叶级页指向表中的记录：记录的物理顺序与逻辑顺序没有必然的联系。

聚簇索引非常象目录表，目录表的顺序与实际的页码顺序是一致的。非聚簇索引则更象书的标准索引表，索引表中的顺序通常与实际的页码顺序是不一致的。一本书也许有多个索引。例如，它也许同时有主题索引和作者索引。同样，一个表可以有多个非聚簇索引。

通常情况下，你使用的是聚簇索引，但是你应该对两种类型索引的优缺点都有所理解。

每个表只能有一个聚簇索引，因为一个表中的记录只能以一种物理顺序存放。通常你要对一个表按照标识字段建立聚簇索引。但是，你也可以对其它类型的字段建立聚簇索引，如字符型，数值型和日期时间型字段。
从建立了聚簇索引的表中取出数据要比建立了非聚簇索引的表快。当你需要取出一定范围内的数据时，用聚簇索引也比用非聚簇索引好。例如，假设你用一个表来记录访问者在你网点上的活动。如果你想取出在一定时间段内的登录信息，你应该对这个表的DATETIME型字段建立聚簇索引。
对聚簇索引的主要限制是每个表只能建立一个聚簇索引。但是，一个表可以有不止一个非聚簇索引。实际上，对每个表你最多可以建立249个非聚簇索引。你也可以对一个表同时建立聚簇索引和非聚簇索引。
假如你不仅想根据日期，而且想根据用户名从你的网点活动日志中取数据。在这种情况下，同时建立一个聚簇索引和非聚簇索引是有效的。你可以对日期时间字段建立聚簇索引，对用户名字段建立非聚簇索引。如果你发现你需要更多的索引方式，你可以增加更多的非聚簇索引。
非聚簇索引需要大量的硬盘空间和内存。另外，虽然非聚簇索引可以提高从表中取数据的速度，它也会降低向表中插入和更新数据的速度。每当你改变了一个建立了非聚簇索引的表中的数据时，必须同时更新索引。因此你对一个表建立非聚簇索引时要慎重考虑。如果你预计一个表需要频繁地更新数据，那么不要对它建立太多非聚簇索引。另外，如果硬盘和内存空间有限，也应该限制使用非聚簇索引的数量。

索引属性

这两种类型的索引都有两个重要属性：
你可以用两者中任一种类型同时对多个字段建立索引（复合索引）；
两种类型的索引都可以指定为唯一索引。
你可以对多个字段建立一个复合索引，甚至是复合的聚簇索引。假如有一个表记录了你的网点访问者的姓和名字。如果你希望根据完整姓名从表中取数据，你需要建立一个同时对姓字段和名字字段进行的索引。这和分别对两个字段建立单独的索引是不同的。当你希望同时对不止一个字段进行查询时，你应该建立一个对多个字段的索引。如果你希望对各个字段进行分别查询，你应该对各字段建立独立的索引。
两种类型的索引都可以被指定为唯一索引。如果对一个字段建立了唯一索引，你将不能向这个字段输入重复的值。一个标识字段会自动成为唯一值字段，但你也可以对其它类型的字段建立唯一索引。假设你用一个表来保存你的网点的用户密码，你当然不希望两个用户有相同的密码。通过强制一个字段成为唯一值字段，你可以防止这种情况的发生。?

http://hi.baidu.com/guobeilei/blog/item/51f55afbda311e116c22eb0e.html

聚集索引基于数据行的键值在表内排序和存储这些数据行。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。有关聚集索引体系结构的详细信息，请参阅聚集索引结构。

每个表几乎都对列定义聚集索引来实现下列功能：

如果未使用 UNIQUE 属性创建聚集索引，数据库引擎将向表自动添加一个 4 字节的 uniqueifier 列。必要时，数据库引擎将向行自动添加一个 uniqueifier 值以使每个键唯一。此列和列值供内部使用，用户不能查看或访问。

查询注意事项
在创建聚集索引之前，应先了解数据是如何被访问的。考虑对具有以下特点的查询使用聚集索引：
使用运算符（如 BETWEEN、>、>=、< 和 <=）返回一系列值。

使用聚集索引找到包含第一个值的行后，便可以确保包含后续索引值的行物理相邻。例如，如果某个查询在一系列销售订单号间检索记录，SalesOrderNumber 列的聚集索引可快速定位包含起始销售订单号的行，然后检索表中所有连续的行，直到检索到最后的销售订单号。返回大型结果集。使用 JOIN 子句；一般情况下，使用该子句的是外键列。使用 ORDER BY 或 GROUP BY 子句。

在 ORDER BY 或 GROUP BY 子句中指定的列的索引，可以使数据库引擎不必对数据进行排序，因为这些行已经排序。这样可以提高查询性能。

列注意事项
一般情况下，定义聚集索引键时使用的列越少越好。考虑具有下列一个或多个属性的列：
唯一或包含许多不重复的值

例如，雇员 ID 唯一地标识雇员。EmployeeID 列的聚集索引或 PRIMARY KEY 约束将改善基于雇员 ID 号搜索雇员信息的查询的性能。另外，可对 LastName、FirstName、MiddleName 列创建聚集索引，因为经常以这种方式分组和查询雇员记录，而且这些列的组合还可提供高区分度。按顺序被访问

例如，产品 ID 唯一地标识 AdventureWorks 数据库的 Production.Product 表中的产品。在其中指定顺序搜索的查询（如 `WHERE ProductID BETWEEN 980 and 999`）将从 ProductID 的聚集索引受益。这是因为行将按该键列的排序顺序存储。由于保证了列在表中是唯一的，所以定义为 IDENTITY。经常用于对表中检索到的数据进行排序。

按该列对表进行聚集（即物理排序）是一个好方法，它可以在每次查询该列时节省排序操作的成本。
聚集索引不适用于具有下列属性的列：
频繁更改的列

这将导致整行移动，因为数据库引擎必须按物理顺序保留行中的数据值。这一点要特别注意，因为在大容量事务处理系统中数据通常是可变的。宽键

宽键是若干列或若干大型列的组合。所有非聚集索引将聚集索引中的键值用作查找键。为同一表定义的任何非聚集索引都将增大许多，这是因为非聚集索引项包含聚集键，同时也包含为此非聚集索引定义的键列。
?
转载于http://www.nowamagic.net/database/db_EffetiveSqlFilter.php

SQL Server

[转]您真的了解SQL的索引吗（索引原理篇）