#### 聚集(聚簇)、非聚集(非聚簇)、二级索引，覆盖索引，及主键自增对聚簇索引的影响 ####

目录

聚簇索引

非聚簇索引

二级索引

以Mysql的InnoDB为例

覆盖索引

主键自增对聚簇索引的好处

主键随机对聚簇索引的坏处

---

聚集和聚簇是一个东西

聚簇索引

索引和数据存储在一块（ 都存储在同一个B*tree 中）。 一般主键索引都是聚餐索引。

因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引（不过，覆盖索引可以模拟多个聚簇索引的情况）。

非聚簇索引

存储的是数据指针。

二级索引

也叫辅助索引，二级索引存储的是记录的主键。

InnoDB里的索引选择

主键索引是聚簇索引。

唯一索引、普通索引、前缀索引等都是二级索引，存储的是记录的主键。

覆盖索引

即不需要回表

手段：将【要获取值的字段】和【查询字段】拼接成一个联合索引，详可见：MySQL 覆盖索引详解 - 掘金

主键自增对聚簇索引的好处

（摘自：https://www.jianshu.com/p/54c6d5db4fe6，仅作个人备份，浏览请看原文）

对于聚簇索引的存储引擎，数据的物理存放顺序与索引顺序是一致的，即：只要索引是相邻的，那么对应的数据一定也是相邻地存放在磁盘上的。它只需要一页一页地写，索引结构相对紧凑，磁盘碎片少，效率也高。

由于主键的值是顺序的，InnoDB把每一条记录都存储在上一条记录的后面。当达到页的最大填充因子时（InnoDB默认的最大填充因子是页大小的15/16，留出的部分空间用于以后修改），下一条记录就会写入新的页中。一旦数据按照这样顺序的方式加载，主键页就会近似于被顺序的记录填满，这也是所期望的结果。

人无完人，总结顺序主键缺点：

对于高并发工作负载，在InnoDB中按主键顺序插入可能会造成明显的争用。主键的上界会成为“热点”。因为所有的插入都发生在这里，所以并发插入可能导致间隙锁竞争。另一个热点可能是auto_increment锁机制；如果遇到这个问题，则可能需要考虑重新设计表或者应用，比如应用层面生成单调递增的主键ID，插表不使用auto_increment机制，或者更改innodb_autonc_lock_mode配置。

主键随机对聚簇索引的坏处

如果主键不是自增id，可以想象，它会干些什么，不断地调整数据的物理地址、分页，当然也有其他一些措施来减少这些操作。

例如从性能的角度考虑，使用UUID作为聚簇索引会很糟糕：它使得聚簇索引的插入变得完全随机，这是最坏的情况，使得数据没有任何聚集特性。

而当采用UUID的聚簇索引的表往插入数据，如图10所示，因为新行的主键值不一定比之前的插入值大，所以InnoDB无法简单的总是把新行插入到索引的最后，而是需要为新的行寻找合适的位置----通常是已有数据的中间位置----并且分配空间。这会增加很多额外的工作，并导致数据分布不够优化。

总结使用UUID作为主键的一些缺点：

• 写入目标页可能已经刷到磁盘上并从缓存中移除，或者是还没有被加载到缓存中，InnoDB在插入之前不得不先找到并从磁盘读取目标页到内存中，这将导致大量的随机I/O；
• 因为写入是乱序的，InnoDB不得不频繁的做页分裂操作，以便为新的行分配空间。页分裂会导致移动大量数据，一次插入最少需要修改三个页而不是一个，包含两个叶子节点和一个父节点。
• 由于频繁的页分裂，页会变得稀疏并被不规则的填充，所以最终数据会有碎片。

把这些随机值载入到聚簇索引以后，需要做一次optimize table来重建表并优化页的填充。