MySQL的索引 - 技术栈

🧠 索引的本质与目的

索引的本质是一种帮助MySQL高效获取数据的有序数据结构。它的核心目标是通过减少需要扫描的数据量，来极大提升查询效率。

你可以将其类比于字典的目录：没有索引（目录），你只能一页一页地翻找（全表扫描）；而有了索引，你可以通过拼音或部首快速定位到目标字所在的页码。

🌳 核心数据结构：为什么是B+树？

虽然哈希、二叉查找树等数据结构也能用于索引，但MySQL的InnoDB等主流存储引擎普遍采用B+Tree作为索引的默认数据结构。这主要基于数据库查询的特殊场景考量。

下表清晰地对比了B+树与其他几种数据结构的差异，这能直观地展示其优势：

数据结构	优点	缺点	是否适合数据库索引
哈希表	等值查询极快，时间复杂度O(1)	无法进行范围查询；不支持索引排序；存在哈希冲突问题。	不适合作为主流索引
二叉查找树	查询效率平均为O(log n)	在数据顺序插入时，会退化成链表，查询效率降至O(n)。	不适合
平衡二叉树(AVL树)	解决了退化问题，保证O(log n)复杂度	每个节点只存储一个数据，树会变得很高，导致磁盘I/O次数过多。	不适合
B+树	矮胖的树形大幅减少磁盘I/O；叶子节点形成有序链表，范围查询极高效；数据全在叶子节点，查询路径长度稳定。	-	非常适合

B+树能够高效工作的一个关键细节是页（Page） 的概念。InnoDB中，数据被存储在固定大小（默认为16KB）的"页"中。B+树的一个节点通常就是一个页的大小，这意味着一次磁盘I/O可以加载一个包含大量键值的节点，从而显著减少访问深层数据所需的I/O次数。

💾 存储引擎的实现差异

虽然都使用B+树，但InnoDB和MyISAM这两种常见存储引擎的实现方式有根本不同，这直接影响了性能表现。

特性	InnoDB (聚集索引)	MyISAM (非聚集索引)
数据与索引存储	数据文件本身（.ibd）即是索引文件，数据行按主键顺序物理存储在B+树的叶子节点上。	索引文件（.MYI）和数据文件（.MYD）分离。索引树的叶子节点存储的是指向数据行物理地址的指针。
主键索引	聚集索引。叶子节点直接保存行的全部数据。	非聚集索引。叶子节点存储数据物理地址。
辅助索引	叶子节点存储的是对应记录的主键值。查询时需要先找到主键，再回表查询主键索引树（即"回表查询"）。	叶子节点存储的也是数据行的物理地址。查询效率与主键索引无异。

为什么InnoDB要这样设计？

主要是为了节省存储空间。如果每个辅助索引的叶子节点都存放完整数据，会造成巨大的数据冗余。通过"主键值+回表"的方式，虽然在查询上多了步骤，但换来了巨大的空间节约，这在多数OLTP（联机事务处理）场景下是值得的权衡。

⚙️ 索引的使用策略与优化

了解原理后，如何用好索引至关重要。

最左前缀原则

这是使用组合索引 的黄金法则。假设有索引 (col1, col2, col3)，它相当于同时拥有 (col1)、(col1, col2) 和 (col1, col2, col3) 的索引能力。但如果你只用 col2 和 col3 作为条件，这个组合索引是无法被使用的。
覆盖索引

如果一个索引包含了查询所需的所有字段，数据库就不需要回表查询，直接从索引中获取数据，这称为覆盖索引。它能极大提升性能。
sql 复制代码
```
-- 假设有索引 (name, age)
SELECT name, age FROM users WHERE name = 'Alice'; -- 可能使用覆盖索引
```
避免索引失效的常见场景
- 在索引列上使用函数或表达式 ：WHERE YEAR(create_time) = 2024 会导致索引失效。应改为范围查询。
- 类型转换 ：字符串类型的索引列，用数字去查询会导致失效，如 WHERE id = '123'（id是整数）。
- 以通配符开头的LIKE查询 ：WHERE name LIKE '%abc' 无法使用索引，而 'abc%' 可以。

🔍 性能分析工具：EXPLAIN

使用 EXPLAIN 命令分析SQL的执行计划是优化查询的必备技能。请重点关注以下几个字段：

type ：连接类型。从优到劣常见的有 const（唯一索引等值）、ref（非唯一索引等值）、range（范围查询）、index（全索引扫描）、ALL（全表扫描，需优化）。
key：实际使用的索引。
rows：预估需要扫描的行数。
Extra ：额外信息。如出现 Using filesort（需要额外排序）或 Using temporary（使用临时表），通常需要优化。出现 Using index 则表示使用了覆盖索引，是好事。

索引的类别

了解MySQL中的索引对设计高效数据库至关重要。下面这个表格汇总了主要的索引类型，方便你快速把握它们的特点和用途。

索引类型	关键特性/作用	创建关键字	是否唯一	是否允许NULL	一个表数量限制	典型应用场景
主键索引	表数据存储的物理依据，数据按此排序	`PRIMARY KEY`	是	否	1个	行唯一标识，如自增ID
唯一索引	保证数据唯一性，避免重复	`UNIQUE`	是	是	多个	邮箱、手机号、身份证号等
普通索引	最基本索引，仅加速查询	`INDEX` 或 `KEY`	否	是	多个	常用于查询条件的非唯一字段，如姓名
组合索引	多列共同组成一个索引	`INDEX` 或 `KEY`	(可选)	(依赖列定义)	多个	多条件查询，如 `(城市, 年龄)`
全文索引	对文本内容进行关键词搜索	`FULLTEXT`	否	是	多个	文章内容搜索、商品描述搜索
空间索引	对空间数据类型（如点、线、面）进行索引	`SPATIAL`	否	否	多个	地理信息系统（GIS）

💡 索引使用要点

物理存储视角：聚簇与非聚簇

聚簇索引 ：在InnoDB中，表数据本身就直接存储在聚簇索引的叶子节点上。一个表只能有一个聚簇索引，通常就是主键索引。这种结构使得按主键查询非常高效。
非聚簇索引 ：在MyISAM中，索引和数据是分开存储的。无论是主键索引还是普通索引，其叶子节点存储的都是指向数据行所在物理地址的指针。

核心数据结构：B+树与哈希

B+树索引 ：MySQL最常用的索引结构。它是一棵矮胖的、多叉的平衡树 ，能有效减少磁盘I/O次数。B+树索引支持范围查询 和排序操作，适用于绝大多数场景。
哈希索引 ：基于哈希表实现，仅支持等值查询 ，速度极快。但不支持范围查询和排序。MySQL中，只有Memory引擎显式支持，InnoDB的自适应哈希索引是内部机制，自动为热点页创建。

组合索引与最左前缀原则

组合索引的威力在于最左前缀原则 。假设有索引 (last_name, first_name)，以下查询能利用索引：

WHERE last_name = 'Wang'
WHERE last_name = 'Wang' AND first_name = 'Lei'
但 WHERE first_name = 'Lei' 则无法使用该索引。因此，列的顺序至关重要。

提升性能的利器：覆盖索引

如果一个索引包含了查询所需的所有字段，数据库就不需要回表查询，直接从索引中获取数据，这称为覆盖索引。它能极大提升性能。例如：

sql 复制代码

-- 假设有索引 (name, age)
SELECT name, age FROM users WHERE name = 'Alice'; -- 可能使用覆盖索引

特殊功能索引

前缀索引 ：对文本列的前N个字符创建索引，能节省空间。例如 CREATE INDEX idx_name ON users(name(10));。
降序索引 ：从MySQL 8.0开始支持，允许索引列按降序存储，优化 ORDER BY column DESC 查询。
不可见索引：将索引设置为对优化器不可见，用于测试删除索引对性能的影响，而无需真正删除。

⚙️ 索引设计原则

权衡读写开销 ：索引能加速查询 ，但会减慢写操作（INSERT/UPDATE/DELETE），因为索引也需要维护。切忌盲目创建过多索引。
优先考虑高选择性列：选择性高的列（即数据几乎不重复，如身份证号）创建索引效果更佳。性别这种低选择性字段，索引效果不大。
使用EXPLAIN分析 ：使用 EXPLAIN 命令分析SQL语句的执行计划，观察是否使用了预期索引，这是优化的关键步骤。

索引失效场景总结

理解索引何时会"失效"，是进行高效查询优化的关键。下面这个表格汇总了常见的索引失效场景、背后的原因及应对策略，帮你快速把握要点。

失效场景	核心原因	关键解决思路
违反最左前缀原则	复合索引的排序像电话簿，必须先按姓氏（首列）找，才能按名字（次列）找。跳过首列直接查后续列，索引的有序性无法利用。	确保查询条件从复合索引的最左列开始且连续。
在索引列上运算或使用函数	索引存储的是原始值。对列进行计算（如`YEAR(column)`、`column + 1`）后，数据库需要逐行计算才能比较，无法直接使用索引树。	将运算或函数操作移至等号右侧的常量端。
隐式类型转换	当条件值的类型与索引列类型不匹配（如字段是字符串，却用数字查询），MySQL需要先进行类型转换，这相当于对索引列使用了函数。	确保查询条件的类型与字段定义的类型完全一致。
OR 连接的条件不全有索引	如果 `OR` 连接的条件中，有一个字段没有索引，优化器可能会认为合并索引结果集或全表扫描的成本更低，从而导致索引失效。	确保 `OR` 两端字段都有索引；或使用 `UNION ALL` 拆分查询。
LIKE 查询以 `%` 开头	B+树索引的有序性依赖于值的前缀。以 `%` 开头进行模糊查询，无法利用索引的顺序进行定位。	避免前缀通配符；必要时考虑使用全文检索。
使用否定操作符（!=, NOT IN）	否定条件通常需要筛选出大部分数据，优化器可能判断全表扫描比通过索引回表查询更高效。	尽量避免，可尝试改为肯定查询或范围查询。
索引选择性过低	如果某列的值重复度非常高（如"性别"列），使用索引查出的数据量巨大，优化器会认为使用索引不如直接全表扫描。	避免为低区分度列创建单列索引，可将其作为复合索引的后缀列。
范围查询后的索引列失效	在复合索引中，如果对前一列进行了范围查询（如 `>`、`<`），后续索引列在这个范围片段内是无序的，无法利用索引快速定位。	在设计复合索引时，尽量将需要范围查询的列放在后面。
优化器放弃索引（回表成本高）	即使使用了索引，但如果需要回表查询的数据量非常大（例如查询结果是表的大部分数据），优化器可能认为直接顺序读取全表的成本更低。	使用覆盖索引（索引包含所有查询字段），避免回表。

💎 核心原则与建议

要避免索引失效，关键在于建立正确的"索引意识"：

理解最左前缀原则：这是使用复合索引的基石，必须牢记。
保持索引列"纯洁"：避免在索引列上进行任何计算、函数调用或类型转换。
优先考虑覆盖索引：如果查询的所有字段都包含在索引中，就可以避免回表，极大提升性能。
权衡索引的利弊：索引不是越多越好。它会占用空间，并增加数据插入、更新和删除时的维护开销。只为最核心的查询路径创建合适的索引。

💎 总结

MySQL索引的高效性建立在B+树这一矮胖、有序的数据结构之上，并通过InnoDB的聚集索引等设计巧妙平衡了查询性能和存储空间。要想真正发挥其威力，关键在于：

理解原理：明白B+树和聚集/非聚集索引的工作机制。
正确使用：严格遵守最左前缀原则，善用覆盖索引。
善用工具 ：使用 EXPLAIN 分析查询，避免索引失效。