在面试过程中，mysql的索引是经常被问到的一个模块，因为索引的使用好不好很大程度上决定了接口的性能，同时也是最能体现程序员在数据库方面水平的一个地方，所以我在这里为大家准备了索引的15个常见问题，希望能够给大家的面试带来帮助。
1. 索引是什么？
2. MySQL索引有哪些类型？
3. 索引什么时候会失效？
4. 哪些场景不适合建立索引？
5. 为什么要用 B+树，为什么不用二叉树和其他树？
6. 一次B+树索引树查找过程
7. 什么是回表？如何减少回表？
8. 什么是覆盖索引？
9. 索引最左前缀原则
10. 什么是索引下推
11. 大表如何添加索引
12. 如何知道语句是否走索引查询？
13. Hash 索引和 B+树区别是什么？在设计索引如何抉择的？
14. 索引有哪些优缺点？
15. 聚簇索引与非聚簇索引的区别
1. 索引是什么？
- 索引是一种能提高数据库查询效率的数据结构。可以比作一本字典的目录，帮你快速找到对应的记录。
- 索引一般存储在磁盘的文件中，它是占用物理空间的。
- 适当的索引能提高查询效率，过多的索引会影响数据库表的插入和更新功能。
2. MySQL索引有哪些类型？
数据结构维度
- B+树索引：所有数据存储在叶子节点，复杂度为O(logn)，适合范围查询。
- 哈希索引: 适合等值查询，检索效率高，一次到位。
- 全文索引：MyISAM和InnoDB中都支持使用全文索引，一般在文本类型char,text,varchar类型上创建。
- R-Tree索引: 用来对GIS数据类型（也就是二代地理数据模型）创建SPATIAL索引。
物理存储维度
- 聚集索引：聚集索引指以主键创建的索引，在叶子节点存储的是表中的数据。（Innodb存储引擎）
- 非聚集索引：非聚集索引指以非主键创建的索引，在叶子节点存储的是主键和索引列。（Innodb存储引擎）
逻辑维度
- 主键索引：特殊的唯一索引，不允许有空值。
- 普通索引：MySQL中基本索引类型，允许空值和重复值。
- 联合索引：多个字段创建的索引，使用时遵循最左前缀原则。
- 唯一索引：索引列中的值必须是唯一的，但是允许为空值。
- 空间索引：MySQL5.7之后支持空间索引，在空间索引这方面遵循OpenGIS几何数据模型规则。
3. 索引什么时候会失效？
- 查询条件包含or，可能导致索引失效.
- 如果字段类型是字符串，where时一定用引号括起来，否则索引失效
- like通配符可能导致索引失效。
- 联合索引，查询的条件列不是联合索引中的第一个列，索引失效。
- 在索引列上使用 mysql 的内置函数，索引失效。
- 对索引列运算（如，+、-、*、/），索引失效。
- 索引字段上使用（！= 或者 < >，not in）时，可能会导致索引失效。
- 索引字段上使用is null， is not null，可能导致索引失效。
- 左连接查询或者右连接查询关联的字段编码格式不一样，可能导致索引失效。
- 使用全表扫描要比使用索引快,则不使用索引。
4. 哪些场景不适合建立索引？
- 数据量少的表，不适合加索引。
- 更新比较频繁的也不适合加索引。
- 区分度低的字段不适合加索引（如性别）。
- where、group by、order by等后面没有使用到的字段，不需要建立索引。
- 已经有冗余的索引的情况（比如已经有a,b的联合索引，不需要再单独建立a索引）。
5. 为什么要用 B+树，为什么不用二叉树？
可以从这几个维度思考：查询是否够快，效率是否稳定，存储数据多少， 以及查找磁盘次数，为什么不是二叉树，为什么不是平衡二叉树，为什么不是 B 树，而偏偏是 B+树呢？
为什么不是一般二叉树？
如果二叉树特殊化为一个链表，相当于全表扫描。平衡二叉树相比于二叉查找树来说，查找效率更稳定，总体的查找速度也更快。
为什么不是平衡二叉树呢？
我们知道在内存比在磁盘的数据，查询效率快得多。如果树这种数据结构作为索引，那每查找一次数据就需要从磁盘中读取一个节点，也就是一个磁盘块，但是平衡二叉树每个节点只存储一个键值和数据，如果是B树，可以存储更多的节点数据，树的高度也会降低，因此读取磁盘的次数就降下来啦，查询效率就快啦。
那为什么不是 B 树而是 B+树呢？
- B+树非叶子节点上不存储数据，仅存储键值，而B树节点中不仅存储键值，也存储数据。innodb 中页的默认大小是 16KB，如果不存储数据，那 么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，这样查找数据进行磁盘的 IO 次数有会再次减少，数据查询的效率也会更快。
- B+树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的，链表连接。那么 B+树的范围查找，排序查找，分组查找以及去重查找就会变得异常简单。
总结：
B+树的优点：
- 它每个节点可以存储更多的数据，树的高度会随之降低，读取磁盘的次数就会降低（和二叉树，平衡二叉树的区别）。
- 它的非叶子节点上存储的都是键值数据，而非表数据，这样就会存储更多的键值，相对应的树的叶子节点就会更多，树就变得会矮胖，这样对磁盘的IO就会再次减少（和B树的区别）。
- B+树的所有数据都在叶子节点上存储，并且数据是按照顺序排列，链表连接，这样它的查询就会变得异常简单。
6. 一次B+树索引树查找过程
有如下表和索引：
CREATE TABLE `employee` (
`id` int(11) NOT NULL,
`name` varchar(255) DEFAULT NULL,
`age` int(11) DEFAULT NULL,
`date` datetime DEFAULT NULL,
`sex` int(1) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_age` (`age`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
insert into employee values(100,'小伦',43,'2021-01-20','0');
insert into employee values(200,'俊杰',48,'2021-01-21','0');
insert into employee values(300,'紫琪',36,'2020-01-21','1');
insert into employee values(400,'立红',32,'2020-01-21','0');
insert into employee values(500,'易迅',37,'2020-01-21','1');
insert into employee values(600,'小军',49,'2021-01-21','0');
insert into employee values(700,'小燕',28,'2021-01-21','1');
执行下面查询SQL，需要执行几次树搜索操作？
select * from Temployee where age=32;
咱们可以先画 idx_age 普通索引的索引结构图，如下：
再画出 id 主键索引，我们先画出聚族索引结构图，如下：
这条 SQL 查询语句执行大概流程是这样的：
- 搜索idx_age 索引树，将磁盘块1加载到内存，由于32<43,搜索左路分支，到磁盘寻址磁盘块2。
- 将磁盘块2加载到内存中，由于32<36,搜索左路分支，到磁盘寻址磁盘块4。
- 将磁盘块4加载到内存中，在内存继续遍历，找到age=32的记录，取得id = 400.
- 拿到id=400后，回到id主键索引树。
- 搜索id主键索引树，将磁盘块1加载到内存，因为300<400<500,所以在选择中间分支，到磁盘寻址磁盘块3。
- 虽然在磁盘块3，找到了id=400，但是它不是叶子节点，所以会继续往下找。 到磁盘寻址磁盘块8。
- 将磁盘块8加载内存，在内存遍历，找到id=400的记录，拿到R4这一行的数据，好的，大功告成。
下篇文章给大家介绍剩下的几个问题，希望大家多多点赞支持！