4. 索引基础：B+树索引结构、聚簇索引与非聚簇索引、联合索引最左前缀原则

索引是数据库性能调优的核心武器。在 Go 慢查询复盘场景中，90% 的性能问题都源于索引设计不当。本章从 B+ 树结构出发，厘清聚簇索引与非聚簇索引的本质差异，并深入剖析联合索引的“最左前缀”原则——这是设计高效索引、避免索引失效的必修课。

4.1 B+树索引结构

B+ 树是 MySQL InnoDB 存储引擎默认的索引结构，也是绝大多数关系型数据库的索引基石。它是一棵平衡多路查找树，所有数据都存储在叶子节点，非叶子节点只存储键值和指针。

核心特征：
  • 非叶子节点（内部节点）： 仅存放索引键值和指向子节点的指针，不存数据行。
  • 叶子节点： 存放完整的数据行（聚簇索引）或主键值+行指针（非聚簇索引）。
  • 叶子节点链表： 所有叶子节点通过双向链表连接，支持高效的范围查询（如 BETWEEN、>、<）。
  • 树高通常为 2~4 层： 即使表中有千万级数据，也只需 2~4 次磁盘 I/O 即可定位目标行。
B+树索引结构示意图 B+树索引结构（InnoDB） 根节点 [50, 120] 内部节点 [10, 30, 45] 内部节点 [80, 100] 内部节点 [140, 180] 叶子节点 [5, 8, 10, 12, 15] 叶子节点 [20, 25, 30, 35] 叶子节点 [80, 85, 90, 100] 叶子节点 [120, 140, 160] B+树关键特性 • 非叶子节点只存键值+指针，不存数据 → 单节点可容纳更多键，降低树高 • 叶子节点存完整数据行（聚簇）或主键+行指针（非聚簇） • 叶子节点双向链表 → 范围查询无需回根节点，顺序扫描性能极佳

4.2 聚簇索引与非聚簇索引

这是索引分类中最核心的二分法，直接决定了数据行的物理存储方式和查询路径。

对比维度 聚簇索引（Clustered Index） 非聚簇索引（Secondary Index）
数据存储 叶子节点直接存储完整数据行 叶子节点存储主键值 + 行指针（InnoDB 中为主键值）
每表数量 只能有 1 个（物理排序决定） 可以有多个（通常建议 3~5 个以内）
默认索引 InnoDB 主键索引即为聚簇索引 除主键外的所有索引（普通索引、唯一索引、联合索引）
查询路径 直接通过 B+ 树定位到数据行，无需回表 先查到主键值，再通过聚簇索引回表查询完整数据
范围查询 极快（叶子节点链表顺序扫描） 较慢（需要多次回表）
插入性能 主键顺序插入极快；随机插入可能触发页分裂 插入时需维护多个索引树，开销较大
复盘经验： 在 Go 慢查询复盘时，如果发现 SQL 使用了非聚簇索引但查询字段不在索引中（即 回表），且回表次数巨大（如百万级），则考虑使用覆盖索引（索引中包含查询所需的所有字段）来消除回表。

4.3 联合索引最左前缀原则

联合索引（Composite Index）是指在一个索引中包含多个列。最左前缀原则决定了联合索引的生效边界：查询条件必须从索引的最左列开始，并且不能跳过中间的列，否则索引部分失效或完全失效。

4.3.1 原则定义

假设有一个联合索引 INDEX idx_a_b_c (a, b, c)，则查询条件必须满足：

  • 必须包含最左列 a，否则索引完全失效。
  • 可以只使用 a，索引生效，但只用到 a 列的排序。
  • 可以使用 a + b，索引生效，用到 a 和 b 两列。
  • 可以使用 a + b + c，索引完全生效。
  • 跳过 b 直接使用 a + c：索引只用到 a 列，c 列无法利用索引（因为 b 被跳过）。

4.3.2 常见索引失效场景

查询条件 索引使用情况 说明
WHERE a = 1 ✅ 完全使用 最左列匹配
WHERE a = 1 AND b = 2 ✅ 完全使用 连续匹配两列
WHERE a = 1 AND b = 2 AND c = 3 ✅ 完全使用 全列匹配
WHERE b = 2 ❌ 索引失效 未包含最左列 a
WHERE a = 1 AND c = 3 ⚠️ 部分使用 只用到 a 列，c 列无法利用索引（b 被跳过）
WHERE a = 1 AND b > 2 AND c = 3 ⚠️ 部分使用 a 和 b 用到索引，c 在范围查询后失效
WHERE a IN (1,2) AND b = 3 ✅ 完全使用 IN 条件不破坏最左前缀
常见误区： 很多人认为“只要查询条件中有索引列就能用到索引”，这是错误的。联合索引的生效严格遵循最左前缀，跳列和范围查询后的列都会导致索引部分失效。在 Go 慢查询复盘时，务必使用 EXPLAIN 查看 key_len 字段，确认实际使用了索引的哪几列。
联合索引最左前缀原则 联合索引最左前缀原则（索引：a, b, c） 列 a（最左列） 列 b 列 c ✅ WHERE a=1 AND b=2 AND c=3 → 完全使用索引（a, b, c 全部生效） ⚠️ WHERE a=1 AND c=3 → 只用到 a 列，c 列失效（跳过 b） ❌ WHERE b=2 → 索引完全失效（未包含最左列 a） 核心规则：查询条件必须从索引最左列开始，且不能跳过中间列

4.4 复盘实战：如何利用索引知识定位慢查询

在 Go 慢查询复盘流程中，索引相关的排查步骤通常如下：

  1. 获取慢查询 SQL： 通过 slow_query_log 或 performance_schema 捕获执行时间超过阈值的 SQL。
  2. 执行 EXPLAIN： 查看 type、key、key_len、rows、Extra 字段。
  3. 判断索引类型：
    • 如果 type = ALL → 全表扫描，需要加索引。
    • 如果 type = ref 或 range 但 rows 很大 → 检查是否只用了部分索引列。
    • 如果 Extra 包含 Using filesort → 排序字段未在索引中。
    • 如果 Extra 包含 Using temporary → 分组或去重未利用索引。
  4. 检查索引失效：
    • 联合索引是否满足最左前缀？
    • 是否在索引列上使用了函数或隐式类型转换？
    • 范围查询（>、<、BETWEEN）后的列是否失效？
  5. 优化方案：
    • 调整联合索引列顺序，将等值条件列放在前面，范围条件列放在后面。
    • 使用覆盖索引消除回表。
    • 拆分大索引为多个小索引（但需权衡写入性能）。
复盘案例： 某 Go 服务中，SQL 为 SELECT * FROM orders WHERE user_id = ? AND status = ? ORDER BY create_time DESC LIMIT 20，执行时间 2.3s。原索引为 idx_user_status (user_id, status)，但 Extra 显示 Using filesort。优化方案：将索引改为 idx_user_status_time (user_id, status, create_time DESC)，排序直接走索引，执行时间降至 5ms。
← 上一章 📖 返回目录 下一章 →