《彻底掌握索引》—— 要点问题（1）

在面试过程中，mysql的索引是经常被问到的一个模块，因为索引的使用好不好很大程度上决定了接口的性能，同时也是最能体现程序员在数据库方面水平的一个地方，所以我在这里为大家准备了索引的十五个问题，希望能够给大家的面试带来帮助。

1. 索引是什么？

• 索引是一种能提高数据库查询效率的数据结构。可以比作一本字典的目录，帮你快速找到对应的记录。
• 索引一般存储在磁盘的文件中，它是占用物理空间的。
• 适当的索引能提高查询效率，过多的索引会影响数据库表的插入和更新功能。
  

2. MySQL索引有哪些类型？

数据结构维度

• B+树索引：所有数据存储在叶子节点，复杂度为O(logn)，适合范围查询。
• 哈希索引: 适合等值查询，检索效率高，一次到位。
• 全文索引：MyISAM和InnoDB中都支持使用全文索引，一般在文本类型char,text,varchar类型上创建。
• R-Tree索引: 用来对GIS数据类型（也就是二代地理数据模型）创建SPATIAL索引。

物理存储维度

• 聚集索引：聚集索引指以主键创建的索引，在叶子节点存储的是表中的数据。（Innodb存储引擎）
• 非聚集索引：非聚集索引指以非主键创建的索引，在叶子节点存储的是主键和索引列。（Innodb存储引擎）

逻辑维度

• 主键索引：特殊的唯一索引，不允许有空值。
• 普通索引：MySQL中基本索引类型，允许空值和重复值。
• 联合索引：多个字段创建的索引，使用时遵循最左前缀原则。
• 唯一索引：索引列中的值必须是唯一的，但是允许为空值。
• 空间索引：MySQL5.7之后支持空间索引，在空间索引这方面遵循OpenGIS几何数据模型规则。

3. 索引什么时候会失效？

• 查询条件包含or，可能导致索引失效.
• 如果字段类型是字符串，where时一定用引号括起来，否则索引失效
• ike通配符可能导致索引失效。
• 联合索引，查询的条件列不是联合索引中的第一个列，索引失效。
• 在索引列上使用 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这一行的数据，好的，大功告成。