面试必备之mysql索引

MySQL索引：从"Hello World"到"Hello Index"

大家好，今天我们来聊聊MySQL索引。如果你觉得索引是个无聊的话题，那你就大错特错了！索引就像是数据库的"目录"，没有它，你的查询可能会像在图书馆里找书一样，翻遍整个书架才能找到你想要的那本。而有了索引，你就能像在Google上搜索一样，秒速找到答案。

1. 索引的"Hello World"

首先，让我们从一个简单的例子开始。假设你有一张表users，里面有100万条用户记录。你想查找用户名为"John"的用户，于是你写了一条SQL：

sql

ini 复制代码

SELECT * FROM users WHERE username = 'John';

如果没有索引，MySQL会怎么做呢？它会从头到尾扫描整张表，逐行检查username字段是否等于"John"。这就像你在图书馆里从第一本书开始，一本一本地翻，直到找到你要的那本。显然，这种方式效率极低。

那么，索引是如何解决这个问题的呢？简单来说，索引就像是一本书的目录，它告诉MySQL："嘿，你要找的'John'在第123456行，直接去那里找吧！"这样，MySQL就不用扫描整张表了，查询速度自然就上去了。

2. 索引的底层存储引擎

MySQL的索引并不是一个独立的东西，它依赖于存储引擎。最常见的存储引擎是InnoDB和MyISAM。我们今天主要聊InnoDB，因为它是MySQL的默认存储引擎，也是最常用的。

InnoDB的索引是基于B+树（B+ Tree）实现的。B+树是一种平衡树，它的特点是所有数据都存储在叶子节点上，而非叶子节点只存储索引信息。这样做的好处是，查询时可以快速定位到叶子节点，减少磁盘I/O操作。

2.1 B+树 vs 二叉树

你可能会问，为什么不用二叉树呢？二叉树不是更简单吗？嗯，这个问题问得好！二叉树确实简单，但它有一个致命的问题：当数据量很大时，二叉树的深度会变得非常深，导致查询效率下降。而B+树通过保持树的平衡，确保了查询效率的稳定性。

举个栗子，假设你有100万条数据，二叉树的深度可能是20层，而B+树的深度可能只有4层。这意味着，B+树只需要4次磁盘I/O就能找到你要的数据，而二叉树可能需要20次。这差距可不是一星半点啊！

3. 索引的数据结构

既然我们提到了B+树，那就不得不深入聊一下它的数据结构。B+树的结构非常巧妙，它由多个节点组成，每个节点包含多个键值对。键是索引的字段值，值则是指向子节点或数据行的指针。

3.1 叶子节点 vs 非叶子节点

B+树的叶子节点存储了所有的数据行，而非叶子节点只存储索引信息。这样做的好处是，查询时只需要遍历非叶子节点，找到对应的叶子节点，然后直接从叶子节点获取数据。这种方式大大减少了磁盘I/O操作，提高了查询效率。

3.2 顺序访问的优势

B+树的另一个优点是，它的叶子节点是双向链表连接的。这意味着，如果你需要按顺序访问数据（比如范围查询），B+树可以非常高效地完成。相比之下，二叉树在这方面就弱爆了，因为它没有这种链表结构，顺序访问时需要频繁地进行树遍历。

4. 索引优化

好了，现在你已经知道了索引的基本原理和数据结构，接下来我们聊聊如何优化索引。毕竟，索引不是万能的，用不好反而会拖慢查询速度。

4.1 选择合适的索引列

首先，选择合适的索引列非常重要。通常来说，你应该选择那些在WHERE子句中频繁使用的列作为索引列。比如，如果你经常根据username查询用户，那么username列就应该建立索引。

但是，并不是所有列都适合建立索引。比如，性别列（gender）只有两个可能的值（男/女），建立索引的效果就不明显。因为索引的选择性太低，查询时仍然需要扫描大量的数据行。

4.2 复合索引

有时候，单列索引并不能满足你的需求。比如，你经常根据username和age两个字段查询用户，那么你可以建立一个复合索引：

sql

scss 复制代码

CREATE INDEX idx_username_age ON users(username, age);

复合索引的顺序非常重要。MySQL会按照索引列的顺序来匹配查询条件。比如，上面的索引可以优化以下查询：

sql

ini 复制代码

SELECT * FROM users WHERE username = 'John' AND age = 30;

但是，如果你只查询age字段，这个索引就派不上用场了：

sql

ini 复制代码

SELECT * FROM users WHERE age = 30;

4.3 索引覆盖

索引覆盖（Covering Index）是指查询的所有字段都包含在索引中，这样MySQL就不需要回表查询数据行，直接从索引中获取数据。这可以大大提高查询效率。

比如，假设你有一个索引idx_username_age，你只需要查询username和age字段：

sql

ini 复制代码

SELECT username, age FROM users WHERE username = 'John';

这个查询就可以利用索引覆盖，直接从索引中获取数据，而不需要回表查询。

4.3 执行计划

mysql explain

4.3.1Extra1 解释

Using where 使用了where条件过滤，需要结合type来看

Using index 覆盖索引

Using index condition 回表

Using filesort order by的字段没有索引

Using tempory group by 和order by同时存在且不同的字段建立临时表

Using join buffer 一般为join且关联的字段都没有建立索引内外层的type均为all

建立索引优化避免嵌套循环计算

4.3.2 type解释

system：系统表，少量数据，往往不需要进行磁盘IO

const：常量连接（主键索引或者唯一索引等值查询）

eq_ref：主键索引(primary key)或者非空唯一索引(unique not null)等值扫描（联合查询）

ref：非主键非唯一索引等值扫描

range：范围扫描

index：索引树扫描

ALL：全表扫描(full table scan)

system>const>eq_ref>ref>range>index>ALL

4.3.3常见索引使用场景

全字段索引 占用磁盘空间大可以走覆盖索引

前缀索引 索引选择性能问题，count(distinct(num(9)))/count(*) 越接近不变，效果越好

占用磁盘空间小，但是需要回表，并且覆盖索引失效

倒叙索引 解决前缀索引前面字符串区分度小的问题（倒叙可以到业务逻辑处理，不体现在sql中）

hash索引 适合等值查询，不适合范围查询有额外的空间和计算消耗（hash冲突，需要存储原字段）

5. 索引的代价

虽然索引可以大大提高查询速度，但它也是有代价的。首先，索引会占用额外的存储空间。其次，每次插入、更新或删除数据时，MySQL都需要维护索引，这会增加写操作的开销。

5.1 索引的选择性

索引的选择性是指索引列中不同值的数量与总行数的比值。选择性越高，索引的效果越好。比如，username列的选择性通常很高，因为每个用户的用户名都是唯一的。而gender列的选择性就很低，因为它只有两个可能的值。

5.2 索引的维护成本

每次插入、更新或删除数据时，MySQL都需要更新索引。如果索引过多，写操作的开销会变得非常大。因此，你需要在查询速度和写操作开销之间找到一个平衡点。

6. 索引与其他知识的联想

最后，让我们把索引与其他知识联系起来，拓宽一下视野。

6.1 索引与搜索引擎

你有没有想过，搜索引擎是如何在几毫秒内从数十亿网页中找到你要的结果的？其实，搜索引擎的核心技术之一就是倒排索引（Inverted Index）。倒排索引与B+树类似，都是通过建立索引来加速查询。只不过，倒排索引是针对文本数据的，而B+树是针对结构化数据的。

6.2 索引与哈希表

你可能会问，为什么不用哈希表来实现索引呢？哈希表的查询速度不是更快吗？嗯，哈希表确实可以在O(1)时间内完成查询，但它有一个致命的缺点：它不支持范围查询。比如，你想查询age在20到30岁之间的用户，哈希表就无能为力了。而B+树可以非常高效地完成这种范围查询。

6.3 6.3.1. 什么是索引下推？

索引下推是MySQL 5.6引入的一项优化技术。它的核心思想是：在存储引擎层尽可能多地过滤数据，减少回表次数。听起来有点抽象？别急，我们慢慢来。

6.3.1.1 传统查询流程

在没有索引下推的情况下，MySQL的查询流程是这样的：

存储引擎根据索引找到符合条件的记录。
存储引擎 将这些记录返回给Server层。
Server层再根据WHERE条件进一步过滤这些记录。

举个例子，假设你有一张表users，并且有一个复合索引(age, city)。你想查询年龄在20到30岁之间，且城市为"北京"的用户：

sql

sql 复制代码

SELECT * FROM users WHERE age BETWEEN 20 AND 30 AND city = '北京';

在没有索引下推的情况下，存储引擎会先根据age字段找到所有年龄在20到30岁之间的记录，然后将这些记录返回给Server层。Server层再根据city字段过滤出城市为"北京"的记录。

6.3.1.2 索引下推的查询流程

有了索引下推之后，查询流程就变成了这样：

存储引擎根据索引找到符合条件的记录。
存储引擎在返回给Server层之前，先根据WHERE条件中的其他字段（比如city）进行过滤。
存储引擎只将最终符合条件的记录返回给Server层。

这样一来，存储引擎在返回数据之前就已经过滤掉了不符合条件的记录，减少了回表次数，从而提高了查询效率。

6.3.2. 索引下推的优势

索引下推的最大优势就是减少了回表次数。回表是指存储引擎根据索引找到记录后，还需要回到主键索引中查找完整的数据行。这个过程涉及到磁盘I/O操作，非常耗时。

通过索引下推，存储引擎可以在返回数据之前就过滤掉不符合条件的记录，从而减少了回表次数，提高了查询效率。

6.3.2.1 举个例子

假设你有一张表users，里面有100万条记录，其中年龄在20到30岁之间的记录有10万条，城市为"北京"的记录有1万条。

没有索引下推：存储引擎会先找到10万条年龄在20到30岁之间的记录，然后将这10万条记录返回给Server层。Server层再根据city字段过滤出1万条城市为"北京"的记录。这意味着存储引擎需要回表10万次。
有索引下推：存储引擎在找到10万条年龄在20到30岁之间的记录后，直接在存储引擎层根据city字段过滤出1万条城市为"北京"的记录，然后将这1万条记录返回给Server层。这意味着存储引擎只需要回表1万次。

看到没？索引下推让回表次数从10万次降到了1万次，查询效率大大提升！

6.3.3. 索引下推的适用场景

索引下推并不是万能的，它有一定的适用场景。通常来说，索引下推在以下情况下效果最好：

复合索引：索引下推通常用于复合索引，因为复合索引包含多个字段，可以在存储引擎层进行更多的过滤。
范围查询：索引下推在范围查询（如BETWEEN、>、<等）中效果显著，因为范围查询通常会返回大量数据，索引下推可以减少回表次数。
高选择性字段：如果WHERE条件中包含高选择性字段（如city），索引下推可以显著减少回表次数。

6.3.4. 索引下推的限制

虽然索引下推很强大，但它也有一些限制：

只适用于二级索引：索引下推只适用于二级索引（非主键索引），因为主键索引已经包含了完整的数据行，不需要回表。
不支持所有存储引擎：索引下推目前只支持InnoDB和MyISAM存储引擎。
不适用于所有查询：索引下推不适用于所有查询，比如某些复杂的WHERE条件可能无法在存储引擎层进行过滤。

6.3.5. 如何启用索引下推？

索引下推是MySQL 5.6及以后版本的默认行为，你不需要手动启用。但是，如果你想确认某个查询是否使用了索引下推，可以通过EXPLAIN命令来查看。

sql

sql 复制代码

EXPLAIN SELECT * FROM users WHERE age BETWEEN 20 AND 30 AND city = '北京';

在EXPLAIN的输出中，如果Extra列显示Using index condition，就表示这个查询使用了索引下推。

6.3.6. 索引下推与其他优化技术的联想

索引下推虽然是一个高级优化技术，但它并不是孤立的。我们可以把它与其他优化技术联系起来，进一步理解它的作用。

6.3.7 索引下推 vs 索引覆盖

索引覆盖（Covering Index）是指查询的所有字段都包含在索引中，这样MySQL就不需要回表查询数据行。索引下推和索引覆盖都可以减少回表次数，但它们的作用方式不同：

索引覆盖：通过将查询字段包含在索引中，避免回表。
索引下推：通过在存储引擎层过滤数据，减少回表次数。

7. 总结

好了，今天的内容就到这里。我们从索引的"Hello World"开始，聊到了底层存储引擎、数据结构、索引优化，甚至还联想到了搜索引擎和哈希表。希望你能从中有所收获，并在实际工作中灵活运用这些知识。

记住，索引就像是数据库的"目录"，没有它，你的查询可能会慢得像蜗牛爬行。但有了它，你的查询就能像火箭一样飞速前进。当然，索引也不是万能的，用不好反而会拖慢查询速度。所以，一定要根据实际情况，合理使用索引。

最后，送给大家一句话："索引虽好，可不要贪多哦！"