第十章：第4节 MySQL进阶篇——聚集索引和非聚集索引

紧跟上节，我们引出了两个概念“聚集索引”和“非聚集索引”，它俩又叫“聚簇索引”和“非聚簇索引”。MyISAM引擎的索引都是“非聚集索引”，InnoBD引擎主键是“聚集索引”，其他都是“非聚集索引”，因为一个表只能有一个“聚集索引”。

加深理解：

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

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

通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。

何时使用聚集索引或非聚集索引?

下面的表总结了何时使用聚集索引或非聚集索引：

我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚集索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。

InnoDB的主键选择与优化

MyISAM引擎不使用聚集索引，我们不去讨论它，我们只去讨论InnoDB怎么建立聚集索引。

在InnoDB中，主键就是聚集索引。虽然上面的表格中推荐了几种聚集索引的使用时机，如果没有特别的需要，请永远使用一个与业务无关的自增字段（ID）作为主键。

经常看到有帖子或博客讨论主键选择问题，有人建议使用业务无关的自增主键，有人觉得没有必要，完全可以使用如学号或身份证号这种唯一字段作为主键。不论支持哪种论点，大多数论据都是业务层面的。如果从数据库索引优化角度看，使用InnoDB引擎而不使用自增主键绝对是一个糟糕的主意。

上节讨论过InnoDB的索引实现，InnoDB使用聚集索引，数据记录本身被存于主索引（一颗B+Tree）的叶子节点上。这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放，因此每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，如果页面达到装载因子（InnoDB默认为15/16），则开辟一个新的页（节点）。

如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页。如下图所示：

这样就会形成一个紧凑的索引结构，近似顺序填满。由于每次插入时也不需要移动已有数据，因此效率很高，也不会增加很多开销在维护索引上。

如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新记录都要被插到现有索引页得中间某个位置：

此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销，同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。

因此，只要可以，请尽量在InnoDB上采用自增字段做主键。

当然也会出现其他特殊的情况，可以不采用自增字段做主键。比如范围查找数据频繁的表。

通过我们对聚集索引的了解，知道聚集索引对范围内的数据查找还是非常快的，聚集索引只需要找到要检索的所有数据中的开头和结尾数据即可。

比如有这样的表，用户的任务日志表。针对这张表的数据，可能不经常用ID获取单个或某一段数据（例如id>5），总是按时间段获取数据。那可以考虑把时间字段设为主键，这样查找时间段的数据时会非常快，比建一个非聚集索引快得多。设为主键，一定要保证时间字段不能出现重复值。当然也可以用时间字段和一个自增长字段建一个联合主键。

楠神建表一直用自增长的int类型ID字段做主键，如没有特殊需要，建议大家最好都用自增int类型做主键。

聚集索引和非聚集的区别大总结

聚集索引表记录的排列顺序与索引的排列顺序一致，优点是查询速度快，因为一旦具有第一个索引值的记录被找到，具有连续索引值的记录也一定物理地紧跟其后，从而缩小了搜索范围，对于返回某一范围的数据效果最好。

聚集索引的缺点是对表进行修改速度较慢，这是为了保持表中的记录的物理顺序与索引的顺序一致，而把记录插入到数据页的相应位置，必须在数据页中进行数据重排，降低了执行速度。

非聚集索引指定了表中记录的逻辑顺序，数据记录的物理顺序和索引的顺序不一致，聚集索引和非聚集索引都采用了B+tree的结构，但非聚集索引的叶子层顺序并不与实际的数据页相同，而采用指向表中的记录在数据页中位置的方式。非聚集索引比聚集索引层次多，添加记录不会引起数据顺序的重组。在有大量不同数据的列上建立非聚集索引，可以提高数据的查询和修改速度。

在对聚集索引列查询时，聚集索引的速度要比非聚集索引速度快。

在对聚集索引列排序时，聚集索引的速度要比非聚集索引速度快。但是如果数据量比较大时，如10万以上，则二者的速度差别不明显。