MyISAM与InnoDB索引差异详解：B+树的不同实现对比

InnoDB和MyISAM是如何利用B+树来实现这两类索引，它们之间又有什么差异呢？今天我们就来聊聊这个话题。

数据库索引主要分为主键索引（Primary Index）与普通索引（Secondary Index）。那么，InnoDB和MyISAM在利用B+树实现这两类索引时，具体采用了哪些不同的设计思路？这正是本文要探讨的核心内容。

一、MyISAM的索引机制

MyISAM存储引擎的索引与数据记录是分开存储的，这种结构被称为非聚集索引（UnClustered Index）。

在主键索引与普通索引的实现上，MyISAM并没有本质的区别：

数据行被存放在一个独立的连续存储区域中；主键索引的叶子节点存储的是主键值以及对应数据记录的指针；普通索引的叶子节点则存储索引列的值和对应记录的指针。

值得一提的是，MyISAM表可以不被定义主键。

主键索引和普通索引实际上是两棵独立的B+树。当通过索引列进行查询时，系统首先定位到B+树的叶子节点，再通过指针找到对应的数据记录。

举例来说明MyISAM的运作方式：

t(id PK, name KEY, sex, flag);

假设表中存在四条记录：

1, shenjian, m, A
3, zhangsan, m, A
5, lisi, m, A
9, wangwu, f, B

其B+树索引结构如上图所示：数据记录单独存储；id作为主键，形成一棵索引树，叶子节点直接指向数据记录；name作为普通索引，也有一棵独立的索引树，叶子节点同样指向数据记录。

二、InnoDB的索引设计

InnoDB的主键索引与数据记录是存储在一起的，这种设计被称为聚集索引（Clustered Index）。

它没有独立的数据行存储区域；主键索引的叶子节点直接存储主键及其对应的完整数据记录（而非指针）。

正因如此，InnoDB基于主键的查询效率非常高。

由于这一特性，InnoDB表必须包含聚集索引：如果表定义了主键，则该主键就是聚集索引；如果表未定义主键，则第一个非空唯一列会被用作聚集索引；否则，InnoDB会自动创建一个隐藏的row-id作为聚集索引。

需要注意的是，聚集索引只能有一个，因为数据行在物理磁盘上只能有一份聚集存储。

InnoDB的普通索引则可以有多个，其实现方式与聚集索引有所不同：普通索引的叶子节点存储的是对应的主键值（而不是数据记录的指针）。

对于InnoDB表的设计，这里有几个实用建议：

尽量避免使用过长的列作为主键（例如char(64)），因为所有普通索引都会存储主键值，可能导致普通索引体积过大；建议使用趋势递增的整型作为主键，由于数据行与索引存储在一起，这样能够减少插入记录时因索引分裂和数据移动带来的性能开销。

仍然使用上面的例子，只是存储引擎换为InnoDB：

t(id PK, name KEY, sex, flag);

表中的四条记录不变：

1, shenjian, m, A
3, zhangsan, m, A
5, lisi, m, A
9, wangwu, f, B

其B+树索引结构如上图所示：id作为主键，数据记录和主键索引树存储在一起；name作为普通索引，有一棵独立的索引树，但其叶子节点存储的是对应记录的主键id值。

例如，当执行查询：

select * from t where name=‘lisi’;

这个过程会先通过name辅助索引定位到B+树叶子节点，获取到id=5，再通过聚集索引定位到具体的行记录。

也就是说，这个查询实际上扫描了两遍索引树。

三、核心要点总结

MyISAM和InnoDB都使用B+树来实现索引，但设计思路截然不同：

MyISAM的索引与数据分开存储，其索引叶子节点存储的是指向数据的指针，主键索引与普通索引在结构上差异不大；InnoDB的聚集索引将数据行与索引统一存储，其聚集索引的叶子节点存储数据行本身，而普通索引叶子节点存储主键值；InnoDB表必须有且只有一个聚集索引；建议使用趋势递增的整数作为InnoDB的主键，而不宜使用过长的列作为主键。

了解其背后的实现原理，比单纯记住结论更为重要。

掌握设计思路往往比技术细节更具价值。