MySQL性能优化[理论篇]-聚簇索引和非聚簇索引,InnoDB和MyISAM

系列文章：

聚簇索引

聚簇索引(Clustered Index)并不是一种新的数据结构，只是B树索引的一种存储方式。

聚簇索引的特点是完整的数据行就放在B树的叶子结点中，Clustered(聚簇,集群)就表示数据行与对应的键紧凑的存储在一起。

下图是《高性能MySQL》聚簇索引的截图，其中，叶子结点包含了数据行的完整数据，非叶子节点只包含索引列数据。

聚簇索引

数据行的逻辑顺序与聚簇索引的顺序一致。B+树中叶子结点以链表的形式串联的，叶子节点中数据行的逻辑顺序只有一种，所以一张表只能有一个聚簇索引。

相反非聚簇索引指的就是数据行和对应的键不存在一起，非聚簇索引中叶子结点一般存的是数据行的引用。

MySQL中索引由存储引擎实现，不同的存储引擎索引的存储结构是不一样的，不是所有的存储引擎都支持聚簇索引。

MySQL支持很多种存储引擎(包括官方的和第三方的)，使用最多的就是InnoDB(5.5之后默认的存储引擎)和MyISAM(5.5之前默认的存储引擎)。

InnoDB存储引擎

InnoDB中主键索引默认是聚簇的。

如果表中没有定义主键，InnoDB会选择一个所有列非空的Unique索引作为聚簇索引。

如果表中既没有主键也没有非空的唯一索引，InnoDB内部会生成一个名为GEN_CLUST_INDEX的隐式聚簇索引。这个隐式的聚簇索引中包含每个数据行的RowID，并以RowID作为隐式主键进行排序。RowID是一个6字节的字段，并随着新行的插入而单调递增，隐式索引中的数据行在物理结构上是按插入顺序顺序存储的。

绝大多数情况下我们都会定义主键的，所以上面说的两种没有主键的情况下面都不考虑。

InnoDB的二级索引会在叶子结点保存主键。

当通过二级索引查找时，InnoDB需要通过二级索引的叶子结点获得对应的主键，然后根据主键从主键索引中找对应的行。也就是说InnoDB查找数据行会经过两个B树。这样做有个好处就是减少了数据行移动或数据页分裂时二级索引的维护工作，但是查找速度会略微变慢，有一种解决方法是实现索引覆盖，让二级索引直接覆盖所需的查询字段，这样就没必要查找数据行，也就没必要走主键索引了。

InnoDB索引存储结构

B+树索引

聚簇索引的优点

聚簇索引将索引和数据行保存在同一个B-Tree中，查询通过聚簇索引可以直接获取数据，而非聚簇索引要进行多次I/O，所以聚簇索引通常比非聚簇索引查找更快。
聚簇索引对主键范围查询的效率很高，因为其数据是按照主键排列的
二级索引使用索引覆盖可以直接使用叶节点的主键值。

聚簇索引的缺点

聚簇索引最大限度地提高了I/O密集型应用的性能，但如果数据都存放在内存中，则访问顺序就不那么重要了，聚簇索引也没什么优势。
插入速度严重依赖于插入顺序。按照主键顺序往InnoDB中进行数据导入是最快的。如果不是按照主键插入，最好在导入完成后使用OPTIMIZE TABLE命令重新组织一下表。
聚簇索引在插入新行和更新主键时，可能导致“页分裂”问题：当插入到某个已满的叶子结点时，B+树会分裂成两个页来容纳新插入的行数据。页分裂会导致表占用更多的磁盘空间（不要用UUID或随机数做主键，而应该使用单调递增的值做主键）。
聚簇索引可能导致全表扫描速度变慢，因为可能需要加载物理上相隔较远的页到内存中（需要耗时的磁盘寻道操作）。
二级索引访问数据行需要两次索引查找，由于二级索引保存了主键列，二级索引会占更大的空间(所以选用一个短主键是有利的)。