聚簇索引并不是一种单独的索引,而是一种数据存储方式.具体的细节依赖于其实现方式,但Innodb的聚簇索引实际上在同一个结构保存了B-Tree索引和数据行 当表有聚簇索引时,它的数据行实际上存放在索引的叶子页中.术语"聚簇"表示数据行和相邻的键值紧凑的存储在一起(这并非总成立)**.因为无法同时把数据行存放在两个不同的地方,所以一个表只能有一个聚簇索引(不过,覆盖索引可以模拟多个聚簇索引的情况)** 因为是存储引擎负责实现索引,因此不是所有的存储引擎都支持聚簇索引. 下面展示聚簇索引中的记录是如何存放.注意到,叶子页包含了行的全部数据,但是节点页只包含了索引列 在这个案列中,索引列包含的是整数值  聚簇索引的数据分布 一些数据库允许选择哪个索引作为聚簇索引,但是到现在没有那个mysql内建的存储引擎支持这一点.Innodb将通过主键聚集数据,这也就是说上图中的"被索引的列"就是主键列 如果没有定义主键,Innodb会选择一个唯一的非空索引代替.如果没有这样的索引,Innodb会隐式定义一个主键来作为聚簇索引.Innodb只聚集在同一个页面中的记录.包含相邻键值的页面可能会相距甚远 聚簇索引可能对性能有帮助,但也可能导致严重的性能问题.所以需要仔细的考虑聚簇索引,尤其是将表的存储引擎从Innodb改成其他存储引擎 聚簇索引有一些优点 * 可以把相关数据保存在一起.例如实现电子邮箱时,可以根据用户ID来聚集数据,这样只需要从磁盘读取少量的数据页就能获取某个用户的全部邮件.如果没有使用聚簇索引,者每封邮件都可能导致一次磁盘IO * 数据访问更快.聚簇索引将索引和数据保存在一个B-Tree中,因此从聚簇索引中获取数据通常比在非聚簇索引中查找要快 * 使用覆盖索引扫描的查询可以直接使用页节点的主键值 如果在设计表和查询时充分利用到上面的优点,那就能极大的提升性能.同时,聚簇索引也有一些缺点 * 聚簇数据最大限度的提高了I/O密集型应用的性能,但如果数据全部都放在内存中,则访问的顺序就没有那么重要了,聚簇索引也就没有什么优势了 * 插入速度严重依赖于插入顺序.按照主键的顺序插入是加载数据到Innodb表中速度最快的方式.但如果不是按照主键顺序加载数据,那么在加载完成后最好使用OPTIMIZE TABLE命令重新组织下表 * 更新聚簇索引的表在插入新行,或者主键被更新导致需要移动行的时候,可能面临页分裂的问题.当行的主键值要求必须将这一行插入到某个已满的页中时,存储引擎会将该页分裂成两个页面来容纳该行,这就是一次分裂操作.页分裂会导致表占用更多的磁盘空间 * 聚簇索引可能导致全表扫描变慢,尤其是行比较稀疏,或者由于页分裂导致数据存储不连续的时候 * 二级索引(非聚簇索引)可能比想象的更大,因为在二级索引的叶子节点包含了引用行的主键列 * 二级索引访问需要进行两次索引查找,而不是一次 **为什么要进行2次索引查找?** **二级索引保存的"行指针",要记住,二级索引叶子节点保存的不是指向行的物理位置的指针,而是行的主键值** **这意味着通过二级索引查找行,存储引擎需要找到二级索引的叶子节点获得对应的主键值,然后根据这个值去聚簇索引中查找对应的行.这里做了重复工作:两次B-Tree查找而不是一次(并不是所有的非聚簇索引都能够做到一次索引查询就能找到行.当行更新的时候可能无法存储在原来的位置,这会导致表中出现行的碎片化或者移动行并在原位置保存"向前指针".这两种情况都会导致在查找行时需要更多的工作).对应Innodb,自适应hash能够减少这样的重复工作**