索引 · 知识库

MD 更新：未知

二级索引（Secondary Index，在 MySQL InnoDB 中也叫辅助索引）对查询速度的影响是双面的。它能极大提升特定条件的查询效率，但在某些情况下，如果使用不当，反而可能成为性能瓶颈。

我们可以从加速机制、核心瓶颈（回表）以及负面影响三个维度来深度解析。

1. 加速机制：从 $O(n)$ 到 $O(\log n)$

如果没有二级索引，数据库为了找到一条记录，必须进行全表扫描（Full Table Scan）。

全表扫描： 数据库需要从物理存储的第一行开始，逐行读取数据到内存进行比对。如果表有 1000 万行，最坏情况下要扫描 1000 万次，这是 $O(n)$ 的复杂度。
二级索引： 二级索引本质上是一棵 B+ 树。它根据索引列的值进行排序和组织。
- 查询时，数据库通过 B+ 树的根节点向下查找，每次都能排除掉绝大多数不符合的数据。
- 对于千万级的数据量，B+ 树的高度通常只有 3-4 层，这意味着只需要 3-4 次磁盘 I/O 就能定位到目标。这是 $O(\log n)$ 的复杂度。

这是理解二级索引性能的关键点。二级索引的叶子节点存储的不是完整的行数据，而是索引列的值 + 主键值。

当你执行 SELECT * FROM users WHERE username = 'Gemini';（假设 username 是二级索引）：

第一步： 在二级索引的 B+ 树中查找到 username = 'Gemini' 的节点，获取到对应的主键 ID（比如 ID = 100）。
第二步： 拿到 ID = 100 后，回到聚簇索引（主键索引）中再次进行一次 B+ 树查找，以获取这一行的完整数据（如 email, age 等）。

这个过程被称为回表。

回表对速度的影响：

如果查询结果只有几条，回表的开销微乎其微。
如果查询结果有上万条，数据库就需要进行上万次主键查找。由于二级索引的顺序和聚簇索引的物理顺序通常是不一致的，这会产生大量的随机 I/O，此时数据库优化器可能会认为“回表太慢了”，从而放弃使用索引，直接走全表扫描。

为了绕过“回表”这个性能杀手，高级开发中常用覆盖索引。

原理： 如果你查询的字段已经全部包含在二级索引中了，数据库就不用回表了。
例子： 你创建了复合索引 INDEX(username, email)。
- 查询：SELECT email FROM users WHERE username = 'Gemini';
- 此时，二级索引里既有 username 也有 email，数据库直接在二级索引树里就能拿到结果并返回。这种查询速度是极快的。

索引并不是越多越好，它们会带来额外的性能成本：

每当你增加一条记录，数据库不仅要维护聚簇索引，还要同步更新所有的二级索引。

二级索引是物理存在的。每个索引都需要占用额外的磁盘空间。在海量数据场景下，索引文件的大小甚至可能超过数据文件本身。

当索引过多时，数据库查询优化器（Optimizer）在生成执行计划时，需要计算并对比每一个索引的成本。过多的索引会增加 SQL 解析和优化的时间。

场景	二级索引的影响
精确匹配 / 范围查询	显著变快（从全表扫描变为树查找）
排序 (ORDER BY)	变快（利用索引的天然有序性，避免内存排序 FileSort）
覆盖索引查询	极快（完全消除回表开销）
全表数据写入	变慢（需要维护多棵 B+ 树）
返回大量行数据	可能失效（回表产生的随机 I/O 过高导致优化器放弃索引）

建议： 在设计时，优先为 WHERE 过滤频繁、JOIN 关联字段、以及 ORDER BY 字段添加二级索引，并尽可能通过联合索引实现覆盖索引来避开回表。