因为索引是MySQL中比较重点的知识，相信很多人都有一定的了解，尤其是在面试中出现的频率特别高。
一、索引是什么?
索引是帮助MySQL高效获取数据的数据结构。能够帮助我们快速的检索数据库中的数据
二、索引能干什么?
索引非常关键，尤其是当表中的数据量越来越大时，索引对于性能的影响愈发重要。 索引能够轻易将查询性能提高好几个数量级，总的来说就是可以明显的提高查询效率。
三、索引的分类?
1、从存储结构(索引存储时保存的形式)上来划分：B+Tree索引（InnoDB引擎默认索引），Hash索引，full-index全文索引，R-Tree索引。
2、从应用层次来分：普通索引，唯一索引，复合索引
- 普通索引：即一个索引只包含单个列，一个表可以有多个单列索引
- 唯一索引：索引列的值必须唯一，但允许有空值
- 复合索引：多列值组成一个索引，专门用于组合搜索，其效率大于索引合并
3、根据中数据的物理顺序与键值的逻辑（索引）顺序关系：聚集索引，非聚集索引。
平时讲的索引类型一般是指在应用层次的划分。
四、索引的底层实现
mysql默认存储引擎innodb只显式支持B-Tree( 从技术上来说是B+Tree)索引，对于频繁访问的表，innodb会透明建立自适应hash索引，即在B树索引基础上建立hash索引，可以显著提高查找效率，对于客户端是透明的，不可控制的，隐式的。
Hash索引
基于哈希表实现，只有精确匹配索引所有列的查询才有效，对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码（hash code），并且Hash索引将所有的哈希码存储在索引中，同时在索引表中保存指向每个数据行的指针。
B-Tree索引（MySQL使用B+Tree）
B-Tree能加快数据的访问速度，因为存储引擎不再需要进行全表扫描来获取数据，数据分布在各个节点之中。
B+Tree索引
是B-Tree的改进版本，同时也是数据库索引索引所采用的存储结构。数据都在叶子节点上，并且增加了顺序访问指针，每个叶子节点都指向相邻的叶子节点的地址。相比B-Tree来说，进行范围查找时只需要查找两个节点，进行遍历即可。而B-Tree需要获取所有节点，相比之下B+Tree效率更高。
五、为什么索引结构默认使用B+Tree，而不是Hash，二叉树，红黑树？
B-tree：因为B树不管叶子节点还是非叶子节点，都会保存数据，这样导致在非叶子节点中能保存的指针数量变少（有些资料也称为扇出），指针少的情况下要保存大量数据，只能增加树的高度，导致IO操作变多，查询性能变低；
Hash：虽然可以快速定位，但是没有顺序，IO复杂度高。
二叉树：树的高度不均匀，不能自平衡，查找效率跟数据有关（树的高度），并且IO代价高。
红黑树：树的高度随着数据量增加而增加，IO代价高。
六、为什么官方建议使用自增长主键作为索引？
结合B+Tree的特点，自增主键是连续的，在插入过程中尽量减少页分裂，即使要进行页分裂，也只会分裂很少一部分。并且能减少数据的移动，每次插入都是插入到最后。总之就是减少分裂和移动的频率。
七、简单总结下
1、MySQL使用B+Tree作为索引数据结构。 2、B+Tree在新增数据时，会根据索引指定列的值对旧的B+Tree做调整。 4、从物理存储结构上说，B-Tree和B+Tree都以页(4K)来划分节点的大小，但是由于B+Tree中中间节点不存储数据，因此B+Tree能够在同样大小的节点中，存储更多的key，提高查找效率。 5、影响MySQL查找性能的主要还是磁盘IO次数，大部分是磁头移动到指定磁道的时间花费。 6、MyISAM存储引擎下索引和数据存储是分离的，InnoDB索引和数据存储在一起。 7、InnoDB存储引擎下索引的实现，(辅助索引)全部是依赖于主索引建立的(辅助索引中叶子结点存储的并不是数据的地址，还是主索引的值，因此，所有依赖于辅助索引的都是先根据辅助索引查到主索引，再根据主索引查数据的地址)。 8、由于InnoDB索引的特性，因此如果主索引不是自增的(id作主键)，那么每次插入新的数据，都很可能对B+Tree的主索引进行重整，影响性能。因此，尽量以自增id作为InnoDB的主索引。
问题1:数据库中最常见的慢查询优化方式是什么？
问：数据库中最常见的慢查询优化方式是什么？ A：加索引。
问：为什么加索引能优化慢查询？A：因为索引其实就是一种优化查询的数据结构，比如Mysql中的索引是用B+树实现的，
而B+树就是一种数据结构，可以优化查询速度，可以利用索引快速查找数据，所以能优化查询。
问：你知道哪些数据结构可以提高查询速度？A：哈希表、完全平衡二叉树、B树、B+树等等。
问题2: InnoDB使用的B+ 树的索引模型，为什么采用B+ 树吗？这和Hash索引比较起来有什么优缺点吗？
A：范围查询，因为Hash索引底层是哈希表，哈希表是一种以key-value存储数据的结构，所以多个数据在存储关系上是完全没有任何顺序关系的，所以，对于区间查询是无法直接通过索引查询的，就需要全表扫描。所以，哈希索引只适用于等值查询的场景。而B+ 树是一种多路平衡查询树，所以他的节点是天然有序的（左子节点小于父节点、父节点小于右子节点），所以对于范围查询的时候不需要做全表扫描
B：B+ Tree索引和Hash索引区别？
哈希索引适合等值查询，但是无法进行范围查询
哈希索引没办法利用索引完成排序
哈希索引不支持多列联合索引的最左匹配规则
如果有大量重复键值的情况下，哈希索引的效率会很低，因为存在哈希碰撞问题
问题3:
Q：B+ Tree的叶子节点都可以存哪些东西吗？
聚簇索引、覆盖索引
A：InnoDB的B+ Tree可能存储的是整行数据，也有可能是主键的值
Q：那这两者有什么区别吗？
A：在 InnoDB 里，索引B+ Tree的叶子节点存储了整行数据的是主键索引，也被称之为聚簇索引。而索引B+ Tree的叶子节点存储了主键的值的是非主键索引，也被称之为非聚簇索引
Q：那么，聚簇索引和非聚簇索引，在查询数据的时候有区别吗？
A：聚簇索引查询会更快
Q：为什么呢？
A：因为主键索引树的叶子节点直接就是我们要查询的整行数据了。而非主键索引的叶子节点是主键的值，查到主键的值以后，还需要再通过主键的值再进行一次查询
Q：刚刚你提到主键索引查询只会查一次，而非主键索引需要回表查询多次。（后来我才知道，原来这个过程叫做回表）是所有情况都是这样的吗？非主键索引一定会查询多次吗？
A：通过覆盖索引也可以只查询一次
覆盖索引？
覆盖索引（covering index）指一个查询语句的执行只用从索引中就能够取得，不必从数据表中读取。也可以称之为实现了索引覆盖。
当一条查询语句符合覆盖索引条件时，MySQL只需要通过索引就可以返回查询所需要的数据，这样避免了查到索引后再返回表操作，减少I/O提高效率。
如，表covering_index_sample中有一个普通索引 idx_key1_key2(key1,key2)。
当我们通过SQL语句：select key2 from covering_index_sample where key1 = 'keytest';的时候，就可以通过覆盖索引查询，无需回表。
问题4:联合索引、最左前缀匹配
Q：在创建索引的时候都会考虑哪些因素呢？
A：一般对于查询概率比较高，经常作为where条件的字段设置索引
Q： 那你们有用过联合索引吗？
A：用过呀，我们有对一些表中创建过联合索引
Q：那你们在创建联合索引的时候，需要做联合索引多个字段之间顺序你们是如何选择的呢？
A：我们把识别度最高的字段放到最前面
Q：为什么这么做呢？
A：这样的话可能命中率会高一点吧。。。
Q： 那你知道最左前缀匹配吗？
A：在创建多列索引时，我们根据业务需求，where子句中使用最频繁的一列放在最左边，因为MySQL索引查询会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。所以当我们创建一个联合索引的时候，如(key1,key2,key3)，相当于创建了（key1）、(key1,key2)和(key1,key2,key3)三个索引，这就是最左匹配原则
问题5:
索引下推、查询优化
Q：你们线上用的MySQL是哪个版本啊呢？
A：我们MySQL是5.7
Q：那你知道在MySQL 5.6中，对索引做了哪些优化吗？
A：不好意思，这个我没有去了解过。（事后我查了一下，有一个比较重要的 ：Index Condition Pushdown Optimization）
Index Condition Pushdown（索引下推）
MySQL 5.6引入了索引下推优化，默认开启，使用SET optimizer_switch = 'index_condition_pushdown=off';可以将其关闭。官方文档中给的例子和解释如下：
people表中（zipcode，lastname，firstname）构成一个索引
SELECT * FROM people WHERE zipcode='95054' AND lastname LIKE '%etrunia%' AND address LIKE '%Main Street%';
如果没有使用索引下推技术，则MySQL会通过zipcode='95054'从存储引擎中查询对应的数据，返回到MySQL服务端，然后MySQL服务端基于lastname LIKE '%etrunia%'和address LIKE '%Main Street%'来判断数据是否符合条件。
如果使用了索引下推技术，则MYSQL首先会返回符合zipcode='95054'的索引，然后根据lastname LIKE '%etrunia%'和address LIKE '%Main Street%'来判断索引是否符合条件。如果符合条件，则根据该索引来定位对应的数据，如果不符合，则直接reject掉。有了索引下推优化，可以在有like条件查询的情况下，减少回表次数。
问题7
Q：你们创建的那么多索引，到底有没有生效，或者说你们的SQL语句有没有使用索引查询你们有统计过吗？
A：这个还没有统计过，除非遇到慢SQL的时候我们才会去排查
Q：那排查的时候，有什么手段可以知道有没有走索引查询呢？
A：可以通过explain查看sql语句的执行计划，通过执行计划来分析索引使用情况
Q：那什么情况下会发生明明创建了索引，但是执行的时候并没有通过索引呢？
A：（大概记得和优化器有关，但是这个问题并没有回答好）
查询优化器？
一条SQL语句的查询，可以有不同的执行方案，至于最终选择哪种方案，需要通过优化器进行选择，选择执行成本最低的方案。
在一条单表查询语句真正执行之前，MySQL的查询优化器会找出执行该语句所有可能使用的方案，对比之后找出成本最低的方案。
这个成本最低的方案就是所谓的执行计划。优化过程大致如下：
1、根据搜索条件，找出所有可能使用的索引
2、计算全表扫描的代价
3、计算使用不同索引执行查询的代价
4、对比各种执行方案的代价，找出成本最低的那一个
Q：哦，索引有关的知识我们暂时就问这么多吧。你们线上数据的事务隔离级别是什么呀？
A：(后面关于事务隔离级别的问题了，就不展开了)
