目录
1、聚簇索引
一篇聚簇索引数据结构的文章：聚簇索引数据结构
聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。InnoDB存储引擎的聚簇索引的背后数据结构就是 B-Tree或者B-Tree的变种B+Tree。
当表有聚簇索引时，它的数据行实际上存放在索引的叶子页中，也就是 B+Tree的叶子节点上。因为数据行不能存在两个地方，所以一个表只能有一个聚簇索引。
如下图所示，叶子页包含了行的全部数据，但是节点页只包含了索引列（可以理解为只是更好索引数据的指针）。
InnoDB 通过主键聚集数据，上图被索引的列就是主键列。
如果没有定义主键，InnoDB 会选择一个唯一的非空索引代替。如果没有这样的索引，InnoDB 会隐式定义一个主键来作为聚簇索引。
优点
1. 可以把相关数据保存在一起。例如查找用户名时，可以根据用户id来聚集数据，这样只需要从磁盘读取少数的数据页就能获取某个用户的名称。如果没有使用聚簇索引，则每条记录都可能导致一次磁盘 I/O。
2. 数据访问更快。聚簇索引将索引和数据保存在同一个 B+Tree中，因此从聚簇索引中获取数据通常比在非聚簇索引中查找更快。
3. 使用 覆盖索引扫描的查询可以直接使用叶节点中的主键值。
缺点
1. 聚簇数据最大限度地提高了 I/O 密集型应用的性能，但如果数据全部都放在内存中，则访问的熟悉怒就没那么重要了，聚簇索引也就没有什么优势了。
2. 插入速度严重依赖于插入顺序。按照主键的顺序插入是加载数据到 InnoDB 表中速度最快的方式。
3. 更新聚簇索引列的代价很高，因为会强制 InnoDB 将每个被更新的行移动到新的位置。
4. 基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临“页分裂”的问题。当行的主键值要求必须将这一行插入到已满的页中时，存储引擎会将该页分裂成两个页面来容纳该行，这就是一次页分裂操作。页分裂会导致表占用更多的磁盘空间。
5. 聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于也分裂导致数据存储不连续的时候。
6. 二级索引（非聚簇索引）可能比想象的要更大，因为在非聚簇索引的叶子节点包含了引用行的主键列。
7. 非聚簇索引访问需要两次索引查找，而不是一次。
聚簇索引在 InnoDB 和 MyISAM 中的区别
https://blog.csdn.net/ruanhao1203/article/details/97954949
2、非聚簇索引
非聚簇索引也是B-Tree数据结构，它的叶子节点包含了引用行的主键列。这意味着通过非聚簇索引查找行，存储引擎需要找到非聚簇索引的叶子节点获得对应的主键，然后根据这个主键值去聚簇索引中查找到对应的行。这里做了至少两次的 BTree 查找。
为什么不止两次查找呢？
当行更新的时候可能无法存储在原来的位置，这会导致表中出现行的碎片化或者移动行并在原位置保存“向前指针”，这两种情况都会导致查找行时需要更多的工作。
如下图：非聚簇索引包含当前列和主键列，如果主键列比较大，会造成非聚簇索引比较大。
3、覆盖索引
一个索引包含了所有需要查询的字段的值，就称为覆盖索引。
覆盖索引可以直接获取列的数据，而不用在读取数据行，所以效率比较高。
优点
1. 索引条目通常远小于数据行大小，所以如果只需要读取索引，那MySQL 就会极大地减少数据访问量。
2. 因为索引是按照列值顺序存储的（至少在单个页内是如此），所以对于 I/O 密集型的范围查询会比随机从磁盘读取每一行数据的 I/O 要少得多。
3. 由于 InnoDB 的聚簇索引，覆盖索引对 InnoDB 表特别有用。InnoDB 的非聚簇索引在叶子节点中保存了行的主键值，所以如果运用覆盖索引覆盖需要索引的列，则可以避免对主键索引（聚簇索引）的二次查询。
应用覆盖索引
例如创建表 fgsy 字段如下
覆盖索引如下
如下图，只有select里面选择的字段在覆盖索引内，才可以使用覆盖索引。
下面这种方式就不能运用覆盖索引，因为无法覆盖 所有列。
加上where条件的查询
这三种查询的type分别是：index，all，ref，这里单开一篇讲解 执行计划type
3839
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
