聚簇索引和非聚簇索引以及二级索引

文章来源：http://www.cnblogs.com/Arlen/articles/1605626.html

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

关于mysql是否支持聚簇索引的问题：

我用标准sql尝试建立聚簇索引会出错，如类似这样的sql:CREATE CLUSTERED INDEX mycolumn_clust_index ON arlentest(gid)，错误如下：

Error Code : 1064
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CLUSTERED INDEX mycolumn_clust_index ON arlentest(gid)' at line 1

注：myisam和innodb都一样的错误。

下面这段话来自网络：

一些DBMS允许用户指定聚簇索引，但是MySQL的存储引擎到目前为止都不支持。InnoDB对主键建立聚簇索引。如果你不指定主键，InnoDB会用一个具有唯一且非空值的索引来代替。如果不存在这样的索引，InnoDB会定义 一个隐藏的主键，然后对其建立聚簇索引。一般来说，DBMS都会以聚簇索引的形式来存储实际的数据，它是其它二级索引的基础。

由此看来，只有innodb支持，但它不支持你自己建，而是它帮你主动建，而且只能在主键上建聚簇索引。

 

如何区分聚簇索引和非聚簇索引？这里有一个比喻，来自网络： 

举例来说明一下聚集索引和非聚集索引的区别： 

其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。 

我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。 

如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。 

我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。 

通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。 

进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。

 

网上关于二级索引的解释：

二级索引也是有两个字段的有序文件：

第一个字段是索引字段，有相同的数据类型，并且是数据文件中的非排序字段，

第二个字段可以是一个块指针也可以是记录指针。二级索引（也称为非聚簇索引）用于在二级键上搜索文件，二级索引的搜索键指定了一个顺序，这个顺序与文件的排序顺序不同。例如，对于图3.16所示的EMPLOYEE薪水册文件，可能用雇员标识符（EMP.ID）作为构建主索引的主键，而雇员的姓和名（EMP.LNAME和EMP.FNAME）可能用于构建二级索引。因此，用户产生的搜索操作可以通过雇员标识符（EMP.ID）或者雇员的名字（EMP.FNAME和EMP.LNAME）来访问记录。

 

关于索引的基本知识：

 

1、关于索引

　　前面我们已经提到，关系数据库的世界是一个表的集合，而表又是行和列的集合。在发布一条SELECT查询从表中进行检索行时，得到另一个行和列的集合。当然，现实世界是相当不同的。数据库管理系统实现了抽象的概念，但是在实际的硬件范围内要受到实际的物理约束。结果是，查询要花时间，有时要花很长的时间。

　　假设你想找到某书中的某一个句子。你可以一页一页地逐页搜索，但这会花很多时间。而通过使用本书的索引，你可以很快地找到你要搜索的主题。

　　表的索引与书的目录索引非常相似，都可以极大地提高查询的速度。对一个较大的表来说，通过加索引，一个通常要花费几个小时来完成的查询只要几分钟就可以完成。因此没有理由不对需要频繁查询的表增加索引。

　　假设你已经通过本书的索引找到了一个句子所在的页码。一旦已经知道了页码后，你很可能漫无目的翻寻这本书，直至找到正确的页码。通过随机的翻寻，你最终可以到达正确的页码。但是，有一种找到页码的更有效的方法。

　　首先，把书翻到大概一半的地方，如果要找的页码比半本书处的页码小，就书翻到四分之一处，否则，就把书翻到四分之三的地方。通过这种方法，你可以继续把书分成更小的部分，直至找到正确的页码附近。这是找到书页的非常有效的一种方法。

　　MySQL索引的工作方式与此相似。一个表索引由一组页组成，这些页构成了一个树形结构。根页通过指向另外两个页，把一个表的记录从逻辑上分成和两个部分。而根页所指向的两个页又分别把记录分割成更小的部分。每个页都把记录分成更小的分割，直至到达叶级页。

2、选择索引

　　这里我们要引入两个比较难理解但很重要的概念：聚簇索引和非聚簇索引。这是索引的两种类型。在聚簇索引中，索引树的叶级页包含实际的数据：记录的索引顺序与物理顺序相同。在非聚簇索引中，叶级页指向表中的记录：记录的物理顺序与逻辑顺序没有必然的联系。

　　聚簇索引非常象目录表，目录表的顺序与实际的页码顺序是一致的。非聚簇索引则更象书的标准索引表，索引表中的顺序通常与实际的页码顺序是不一致的。一本书也许有多个索引。例如，它也许同时有主题索引和作者索引。同样，一个表可以有多个非聚簇索引。通常情况下，你使用的是聚簇索引，但是你应该对两种类型索引的优缺点都有所理解。

　　从建立了聚簇索引的表中取出数据要比建立了非聚簇索引的表快。当你需要取出一定范围内的数据时，用聚簇索引也比用非聚簇索引好。例如，假设你用一个表来记录访问者在你网点上的活动。如果你想取出在一定时间段内的登录信息，你应该对这个表的DATETIME（日期时间）型字段建立聚簇索引。假如你不仅想根据日期，而且想根据用户名从你的网点活动日志中取数据。在这种情况下，同时建立一个聚簇索引和非聚簇索引是有效的。你可以对日期时间字段建立聚簇索引，对用户名字段建立非聚簇索引。如果你发现你需要更多的索引方式，你可以增加更多的非聚簇索引。

　　但非聚簇索引需要大量的空间和。另外，虽然非聚簇索引可以提高从表中取数据的速度，它也会降低向表中插入和更新数据的速度。每当你改变了一个建立了非聚簇索引的表中的数据时，必须同时更新索引。因此你对一个表建立非聚簇索引时要慎重考虑。如果你预计一个表需要频繁地更新数据，那么不要对它建立太多非聚簇索引。另外，如果硬盘和内存空间有限，也应该限制使用非聚簇索引的数量。