索引，在MySQL中也叫做键（key），是存储引擎用于快速找到记录的一种数据结构。

每一个索引在 InnoDB 里面对应一棵 B+ 树。

B-Tree索引

　　存储引擎以不同的方式使用B-Tree索引,性能也各有不同,各有优劣
　　MyISAM使用前缀压缩技术使得索引更小，InnoDb则按照原数据格式进行存储。
　　MyISAM索引通过数据的物理位置引用被索引的行，Innodb则根据主键引用被索引的行.
　　B-Tree索引适用于全值键、键值范围、键前缀的查找，其中键前缀查找遵循最左前缀原则。
　　B-Tree索引的限制：
如果不是按照索引的最左列开始查找，则无法使用索引。
不能跳过索引中的列。比如组合索引key（firstName,lastName,birthday）无法用于查找firstName为Smith并且在某个birthday出生的人。如果不指定lastName，则MySQL只能使用索引的第一列firstName。
如果查询中有某个列的范围查询，则其右边所有列都无法使用索引优化查找。例如有查询WHERE last_name=’Smith’ AND first_name LIKE ‘j%’ AND dob=’1976-12-23’，这个查询只能使用索引的前两列，因为这里LIKE是一个范围条件。

聚簇索引

　　聚簇索引实际不是一种索引，而是一种数据的存储方式，InnoDB的聚簇索引在同一个结构中保存了B-Tree索引和数据行。
　　当表有聚簇索引时，他的数据行实际存在放叶子页。InnoDb通过主键聚集数据，如果没有定义主键，则InnoDB会选择一个唯一的非空索引代替。如果也没有也没有合适的唯一索引时，Innodb隐含创建一个包含rowid 的聚簇索引

聚簇索引的优点
　　可以把相关数据保存在一起。例如实现电子邮件时，可以根据用户ID来聚集数据，这样只需要从磁盘读取少数的数据页就能获取某个用户的全部邮件。如果没有使用聚簇索引，则每封邮件都可能导致一次磁盘I/O；
　　数据访问更快。聚簇索引将索引和数据保存在同一个B-Tree中，因此从聚簇索引中获取数据通常比在非聚簇索引中查找更快。
　　使用覆盖索引扫描的查询可以直接使用节点中的主键值。

聚簇索引的缺点
　　聚簇索引最大限度的提高了I/O密集型应用的性能，但如果数据全部都放在内存中，则访问的顺序就没有那么重要了，聚簇索引也就没有那么优势了；
　　插入速度严重依赖于插入顺序。按照主键的顺序插入是加载数据到InnoDB表中速度最快的方式。但如果不是按照主键顺序加载数据，那么在加载完成后最好使用OPTIMIZE TABLE命令重新组织一下表，以消除数据存储碎片。
　　更新聚簇索引列的代价很高，因为会强制InnoDB将每个被更新的行移动到新的位置。
　　基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临页分裂的问题。当行的主键值要求必须将这一行插入到某个已满的页中时，存储引擎会将该页分裂成两个页面来容纳该行，这就是一次分裂操作。页分裂会导致表占用更多的磁盘空间。
　　聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候。
　　二级索引(非聚簇索引)可能比想象的要更大，因为在二级索引的叶子节点包含了引用行的主键列。
　　二级索引访问需要两次索引查找，而不是一次。

InnoDB的主键索引和二级索引

　　在InnoDB中，聚簇索引就是表，聚簇索引的每个叶子节点都包含了主键值、事务ID、用于事务和MVCC的回滚指针以及所有的剩余列。如果主键是一个列前缀索引，InnoDB也会包含完整的主键列和剩下的其他列。
　　InnoDB二级索引的叶子节点中存储的不是“行指针”，而是主键值，并以此作为指向行的“指针”。这样的策略减少了当出现行移动或者数据页分裂时二级索引的维护工作。
　　使用主键值当作指针会让二级索引占用更多的空间，换来的好处是，InnoDB在移动行时无需更新二级索引中的这个“指针”。

为什么主键id最好使用自增id，而不是用UUID等不连续的id？
　　从性能的角度考虑，使用UUID作为聚簇索引会很糟糕：它使得聚簇索引的插入变得完全随机，这是最坏的情况，使得数据没有任何聚集特性。
　　通过测试，向UUID主键插入行不仅花费的时间更长，而且索引占用的空间也更大。这一方面是由于主键字段更长，另一方面毫无疑问是由于页分裂和碎片导致的。这是由于当主键的值是顺序的，则InnoDB将把每一条记录都存储在上一条记录的后面。当达到页的最大填充因子时(InnoDB默认的最大填充因子是页大小的15/16，留出的部分空间用于以后修改)，下一条记录就会写入新的页中。一旦数据按照这样顺序的方式加载，主键页就会近似于被顺序的记录填满，这也是所期望的结果。
　　而当采用UUID的聚簇索引的表插入数据，因为新行的主键值不一定比之前的插入值大，所以InnoDB无法简单的总是把新行插入到索引的最后，而是需要为新的行寻找合适的位置（通常是已有数据的中间位置），并且分配空间。这会增加很多额外的工作，并导致数据分布不够优化。
　　UUID做主键的缺点：
写入目标页可能已经刷到磁盘上并从缓存中移除，或者是还没有被加载到缓存中，InnoDB在插入之前不得不先找到并从磁盘读取目标页到内存中，这将导致大量的随机I/O；
因为写入是乱序的，InnoDB不得不频繁的做页分裂操作，以便为新的行分配空间。页分裂会导致移动大量数据，一次插入最少需要修改三个页而不是一个页。
由于频繁的页分裂，页会变得稀疏并被不规则的填充，所以最终数据会有碎片。
把这些随机值载入到聚簇索引以后，需要做一次optimize table来重建表并优化页的填充。

 

覆盖索引

　　如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为“覆盖索引“。
　　由于InnoDB的聚簇索引，覆盖索引对InnoDB表特别有用。InnoDB的二级索引在叶子节点中保存了行的主键值，所以如果二级主键能够覆盖查询，则可以避免对主键索引的二次查询，也就是回表。
在使用explain查询执行计划时，当explain的输出结果Extra字段为Using index时，即表示触发了覆盖索引。这里需要和输出结果type字段为index做区分，type:index代表使用索引扫描来做排序

使用索引扫描来排序
　　扫描索引本身是很快的，因为需要从一条索引记录移动到紧接着的下一条记录。但如果索引不能覆盖查询所需的全部列，那就不得不每扫描一条索引记录就都回表查询一次对应的行。这基本上都是随机I/O，因此按索引顺序读取数据的速度通常比顺序地全表扫描慢，尤其是在I/O密集型的工作负载时。
　　设计索引时应该尽可能使用同一个索引既满足排序，又用于查找行
　　只有当索引的列顺序和ORDER BY子句的顺序完全一致，并且所有列的排序方向（倒序或正序）都一样时，MySQL才能够使用索引来对结果做排序。
　　如果查询需要关联多张表，则只有当ORDER BY子句引用的字段全部为第一个表时，才能使用索引做排序。OEDER BY子句和查找型查询的限制是一样的：需要满足索引的最左前缀的要求；否则，MySQL都需要执行排序操作，而无法利用索引排序。
　　有一种情况下ORDER BY子句可以不满足索引的最左前缀的要求，就是前导列为常量的时候。如果WHERE子句或者JOIN子句中对这些列制定了常量，就可以“弥补“索引的不足。
　　示例：数据库的表rental在列（rental_date,inventory_id,customer_id）上有名为rental_date的索引。
下面是一些不能使用索引做排序的查询：
下面这个查询使用了两种不同的排序方向，但是索引列都是正序排列的：
… WHERE rental_date = ‘2005-05-25’ ORDER BY inventory_id DESC , customer_id ASC;
下面这个查询的ORDER BY子句中引用了一个不在索引中的列：
… WHERE rental_date = ‘2005-05-25’ ORDER BY inventory_id , staff_id;
下面这个查询的WHERE和ORDER BY中的列无法组合成索引的最左前缀:
… WHERE rental_date = ‘2005-05-25’ ORDER BY customer_id;
下面这个查询在索引列的第一列上是范围条件，所以MySQL无法使用索引的其余列：
… WHERE rental_date = ‘2005-05-25’ ORDER BY inventory_id , customer_id;
这个查询在inventory_id列上有多个等于条件。对于排序来说，这也是一种范围查询：
… WHERE rental_date = ‘2005-05-25’ AND inventory_id IN(1,2) ORDER BY customer_id;