聚簇索引，并不是一个单独的索引类型，而是一种数据结构
实际上就是 数据按照某一列进行排列（所以一个表只能有一个聚簇索引）
例如：在InnoDB的聚簇索引实际上是在同一结构中保存了B+Tree索引和数据行
MyISAM不支持聚簇索引
补充：InnoDB一般通过主键聚集数据，假如没有定义主键，也会选择一个唯一的非空索引代替
节点页只记录索引列，叶子页包含了行的全部数据
- 可以把相关的数据都关联起来 例如根据用户ID来聚集数据，只需要在磁盘中读取少部分的页便可以获得该用户的所有数据
- 数据访问更快 聚簇索引将索引和数据保存在了同一个B+Tree上，从而聚簇索引获取数据比非聚簇索引查找更快、
- 使用覆盖索引扫描的查询可以直接使用页节点中的主键值 （覆盖索引扫描还没看）
- 聚簇索引是为了提高I/O密集应用的效率，倘如数据能够全都放进内存中的话，聚簇索引便没什么用了
- 插入速度严重依赖插入顺序 在InnoDB中，按主键的顺序插入是效率最快的。加入不是按照主键顺序加载数据的话，在加载完成后最好使用 OPTIMIZE TABLE 命令重新组织下表
- 更新聚簇索引列的代价很高 因为会强制InnoDB将每个被更新的行移动到新的位置
- 基于聚簇索引的表插入新行或者主键被更新导致需要移动行的时候，可能会导致页分裂 例如：往一个已满的页中再插入一条数据，需要分裂出新的一页来放这些数据，浪费磁盘空间
- 聚簇索引会导致全表扫描变慢 特别是行比较稀疏，或者由于页分裂导致数据存储不连续的时候
- 二级索引（非聚簇索引）可能会比想象中大 因为二级索引的叶子节点包含了引用行的主键列？？？
- 二级索引需要二次查找 存储引擎首先需要在二级索引的叶子节点找到对应的主键值，然后在通过主键值去聚簇索引中找到对应的行 在InnoDB中，自适应哈希索引能够减少这样的重复工作