聚簇索引是一种数据存储方式。
当表有聚簇索引时，它的数据行实际存放在索引的叶子页中（leaf page）。术语“聚簇”表示数据行和相邻的键值紧凑的存储在一起。因为无法同时把数据行存放在两个不同的地方，所以一个表只有一个聚簇索引。
图展示聚簇索引中的记录是如何存放的。需要注意的是,叶子页包含了行的全部数据，但是节点页只包含了索引列
Innodb将通过主键聚集数据，也就是说上图中的“被索引的列”就是主键列
如果没有定义主键，InnoDB会选择一个唯一的非空索引代替。如果没有这样的索引，InnoDB会隐式定义一个主键来作为聚簇索引。
优点：
- 可以把相关数据保存在一起。例如实现电子邮箱时，可以根据用户ID来聚集数据。这样只需要从磁盘读取少数的数据也就能获取某个用户的全部邮件。如果没有使用聚簇索引，则每封邮件都可能导致一次磁盘I/O
- 数据访问更快。聚簇索引将索引和数据保存在同一个B-Tree中，因此从聚簇索引中读取数据通常比非聚簇索引查找还要快。
- 使用覆盖索引扫描的查询可以直接使用页节点中的主键值(也就是说，联合索引中，不仅包含了指定的列值，还包含了主键的值)
缺点
- 聚簇数据最大限度地提高了I/O密集型应用的性能，但是如果数据全部放在内存中，则访问的顺序就没那么重要了，聚簇索引也就没什么优势了
- 插入速度严重依赖于插入顺序。按照主键的顺序插入是加载数据到InnoDB表中速度最快的方式。但如果不是按照主键顺序加载数据，那么在加载完成后最好使用OPTIMEIZE TABLE命令重新组织一下表
- 更新聚簇索引列的代价很高，因为会强制InnoDB将每个被更新的行移动到新的位置
- 基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临“页分裂（page split）”的问题。当行的主键值要求必须将这一行插入到某个已满的页中时，存储引擎会将该页分裂成两个页面来容纳改行，这就是一次页分裂操作。页分裂会导致表占用更多的磁盘空间。
- 聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据数据存储不连续的时候。
- 二级索引（非聚簇索引）可能比想象的要更大，因为在二级索引的叶子结点包含了引用行的主键列
- 二级索引访问需要两次索引查找，而不是一次
关于最后一点，如果在查找中没有使用到索引覆盖，因为二级索引叶子节点保存的不是指向行的物理位置的指针，而是行的主键值。那么通过二级索引，就首先要获取到主键值，然后根据这个值去聚簇索引中查找到对应的行。
注意点
- 组簇索引的每一个叶子节点都包含了主键值、事务ID、用于事务和MVCC的回滚指针以及所有剩余的列。如果主键是一个列前缀索引，InnoDB也会包含完成的主键列和剩下的其他列。
- 插入数据的时候，主键最好是顺序插入的。因为顺序插入的主键，新增的记录总是插入到原有记录的最后面。 如果不是顺序插入，将会有如下的问题：
- 写入的目标也可能已经刷到磁盘上并从缓存中移除，或者是还没有被加载到缓存中，InnoDB在插入之前不得不先到并从磁盘读取目标也到内存中。这将导致大量的随机I/O
- 因为写入是乱序的，InnoDB不得不频繁地做页分裂操作，以便为新的行分布空间。页分裂会导致移动大量数据，一次插入最少需要修改三个页而不是一个页。
- 由于频繁的页分裂，也会变得稀疏并被不规则的填充，所以最终数据会有碎片
