人人都会AI编程

5.4 聚簇索引与二级索引的结构差异

更新时间：2026-07-11

在 InnoDB 中，索引并不是一张简单的“目录表”，而是直接决定了数据在磁盘上的物理组织方式。理解聚簇索引和二级索引的结构差异，是掌握索引原理最关键的一步，也是日常优化中判断查询性能的根本依据。

5.4.1 聚簇索引：数据即索引，索引即数据

聚簇索引（Clustered Index）并不是一个单独的索引文件，而是数据本身的组织方式。在 InnoDB 中，每张表只有一个聚簇索引，行数据与聚簇索引的叶子节点绑定在一起。

它的 B+ 树结构是：

  • 非叶子节点：存放主键值（或隐式行 ID）以及指向下一层页面的指针，只存索引键，不存行数据。
  • 叶子节点：存放的是完整的行记录，包括所有列。数据页内的行记录按主键顺序排列，页与页之间也按主键顺序通过双向链表连接。

这意味着，当你通过主键查询一行数据（WHERE id = 100）时，InnoDB 从根节点开始，经历若干次页面查找，最终在叶子节点直接拿到了这一行的全部字段——一次到位，不需要再来回翻找。

聚簇索引的建立规则很明确，InnoDB 会依次按以下优先级来决定聚簇索引：

  1. 如果表显式定义了 PRIMARY KEY，就用它。
  2. 如果没有主键，但有一个 UNIQUE 索引且所有列都 NOT NULL，就用第一个这样的唯一索引。
  3. 如果以上都没有，InnoDB 会在内部生成一个隐藏的 row_id，是一个 6 字节的自增整型，以此作为聚簇索引键。

对于开发来说，永远建议显式定义主键，因为隐式 row_id 只能在单个实例内保证唯一，主从复制、迁移时可能引起隐患，而且自增主键对写入性能更友好（后面会讲）。

5.4.2 二级索引：指向主键的“便签”

二级索引（Secondary Index），也叫辅助索引、非聚簇索引，是通过 CREATE INDEX 或 UNIQUE 约束创建的所有索引。它的结构同样是 B+ 树，但叶子节点的内容与聚簇索引完全不同：

  • 非叶子节点：存放索引列的值和指向下一层的指针，与聚簇索引逻辑相同。
  • 叶子节点：存放的是索引列的值 + 对应的主键值。没有完整的行数据。

比如在表 users(id INT PRIMARY KEY, name VARCHAR(50), age INT) 上为 name 列建立索引，那么该索引的叶子节点存放的就是 (name, id) 对。这里的 id 就是主键值。

这意味着，通过二级索引查找数据时，查询并不是在二级索引里就能结束的：

  1. 先在二级索引的 B+ 树中根据 name 找到对应的叶子节点，拿到主键 id。
  2. 再拿着这个 id，回到聚簇索引的 B+ 树中查找完整行记录。

这个过程就是我们常说的回表。如果查询需要的列刚好全部包含在二级索引的叶子节点里（即索引覆盖），那就不需要回表，性能明显更好。

5.4.3 结构差异的三个关键比较

把聚簇索引和二级索引放在一起看，它们的差异主要体现在叶子节点内容、查询行为和对主键设计的依赖上。

1. 叶子节点存放内容不同

  • 聚簇索引叶子节点：存完整行数据（包括所有列）。
  • 二级索引叶子节点：仅存索引列 + 主键值。

因此，在列数较多的大表上，二级索引通常比聚簇索引小得多，对磁盘和缓存更友好。但另一方面，二级索引查到的只是 “半成品”，要获得完整数据还得通过主键再查一次聚簇索引。

2. 查询路径不同

  • 主键查询：直接访问聚簇索引 B+ 树，一次到位。
  • 二级索引查询：
  • 若所需列全在索引中（覆盖索引），就在二级索引 B+ 树上完成，不回表。
  • 若需要其他列，则先查二级索引拿主键，再查聚簇索引拿完整行，两次 B+ 树查找。

一次回表可能意味着额外的磁盘随机 I/O，对高并发查询影响显著。这也是为什么 SELECT * 在有合适二级索引时往往不是最佳选择，因为多数情况下会强制回表。

3. 对主键设计的依赖不同

  • 聚簇索引的性能直接受主键值和插入顺序影响。如果主键是乱序的（如 UUID），插入新行时经常需要在已有的页面中间“挤”进去，导致页分裂和数据碎片化，写入性能会逐渐变差。自增主键可以保证新行几乎永远追加到最右侧的叶子页，写入高效且磁盘顺序性好。
  • 二级索引的叶子节点存储着主键值，所以主键的大小会“传染”给所有二级索引。如果主键是 bigint（8 字节），那么每个二级索引记录都比主键是 int（4 字节）时大一倍；如果主键是较长的 VARCHAR，二级索引的体积膨胀会更严重，不仅占磁盘，还降低缓存效率。这是设计长字符串主键时需要高度重视的隐性成本。

5.4.4 一个查询的完整路径示例

假设表结构如下：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id INT NOT NULL,
  order_no VARCHAR(32) NOT NULL,
  amount DECIMAL(10,2),
  status TINYINT,
  INDEX idx_user (user_id)
);

执行查询：

SELECT order_no, amount FROM orders WHERE user_id = 1000;

InnoDB 会这样处理：

  1. 在 idx_user 索引（二级索引）的 B+ 树上找到 user_id = 1000 的所有叶子节点。由于叶子节点存的是 (user_id, id)，它能定位到所有满足条件的 id 列表。
  2. 对于每一个 id，回到聚簇索引（id 为主键）的 B+ 树上定位对应的叶子页，取出 order_no 和 amount 列。
  3. 将结果返回给客户端。

如果执行的查询是：

SELECT user_id, id FROM orders WHERE user_id = 1000;

那么只需要在第 1 步就已经拿到了所需的 user_id 和 id，不需要回表。这就是覆盖索引，Extra 字段会显示 Using index。

5.4.5 开发实践中的几个关键启示

结合聚簇索引与二级索引的差异，可以得出一些直接指导实践的结论：

  • 主键尽可能短且有序：优先使用自增整型主键。避免用 UUID 字符串或长组合业务字段做主键，否则会拖累所有二级索引的大小和性能。
  • 尽量利用覆盖索引：在编写查询时，考虑是否可以让索引包含 SELECT、WHERE、ORDER BY、GROUP BY 涉及的所有列，从而避免回表。例如，在需要频繁查询 user_id 和 status 的场景，可以创建 (user_id, status) 联合索引，而不是仅为 user_id 建单列索引。
  • 理解 Extra 中的 Using index 和 Using where：通过 EXPLAIN 查看执行计划，如果看到 Using index 就说明是覆盖索引，无需回表；如果只有 Using where 且 type 为 ref，则可能发生回表。这能帮你快速评估查询是否高效。
  • 二级索引不存完整数据，所以 NOT NULL 约束在索引中更高效：索引中存储的列值若允许 NULL，实现会稍复杂，且 NULL 值在某些情况下可能影响优化器的选择。在设计表时尽量给频繁索引的列加 NOT NULL。
  • 大批量数据导出或扫描时，主键扫描效率远高于二级索引：因为二级索引扫描后每个记录都可能伴随一次随机主键回表，而主键全表扫描是顺序读，吞吐量更高。这个特性在设计报表拉取或数据归档时要考虑在内。

总之，聚簇索引与二级索引的结构差异，决定了从数据插入、存储空间到查询路径的全方位表现。掌握了这一节，你之后再看执行计划、调 SQL、建索引，都会有一个清晰的“地图”在脑子里。