innodb主键索引叶子节点存整行数据，因其实现为聚簇索引，数据与主键索引合一，.ibd文件即主键b+树的物理映像；而myisam索引与数据分离，所有索引叶子节点仅存数据文件中的偏移地址。
InnoDB 和 MyISAM 都用 B+Tree 做索引，但底层数据组织方式完全不同——这不是“实现细节差异”，而是直接决定查询路径、I/O 次数和是否回表的关键分水岭。
为什么 InnoDB 主键索引叶子节点存的是整行数据
InnoDB 表数据文件（.ibd）本身就是主键索引的叶子层。只要定义了主键，所有行记录就按主键值顺序物理存储在 B+Tree 叶子节点里；没显式主键时，InnoDB 会自动生成一个隐藏的 row_id（6 字节整型）作为聚簇键。这意味着：
- 主键查询（如
SELECT * FROM t WHERE id = 123）只需一次 B+Tree 查找，直接拿到完整行 - 范围扫描（如
WHERE id BETWEEN 100 AND 200）天然顺序读盘，局部性好 - 如果主键过长（比如用 UUID 字符串做主键），所有二级索引叶子节点都要存这个大主键，索引体积暴涨
为什么 MyISAM 的所有索引叶子节点只存地址
MyISAM 把索引（.MYI）和数据（.MYD）完全分离。无论主键还是普通索引，B+Tree 叶子节点的 data 域存的都是对应记录在 .MYD 文件中的偏移量（类似指针）。这导致：
- 任意索引查询都必须走两步：先查索引得地址，再按地址读
.MYD—— 但这个“地址”是固定长度的，不随主键变大而膨胀 - 没有“回表”概念，因为主键索引和辅助索引结构一致，都指向同一份数据文件
- 数据行物理位置可能因 DELETE/INSERT 频繁变动，MyISAM 不做重排，
.MYD中会出现空洞，影响顺序扫描效率
二级索引查数据时，InnoDB 必须回表而 MyISAM 不用
这是最常被忽略的实际性能断点。例如对 name 字段建了普通索引：
- InnoDB 的
name索引叶子节点只存name值 + 对应的主键值（比如id=456），查SELECT * FROM t WHERE name='Alice'时，先查name索引得id=456，再回到主键索引查完整行 —— 这就是“回表” - MyISAM 的
name索引叶子节点存的是name='Alice'对应记录在.MYD中的字节偏移，直接跳过去读就行，无需二次索引查找 - 若只查
SELECT id, name（覆盖索引），InnoDB 就不用回表；MyISAM 同样省一次 I/O，但它本来就不需要回表，所以覆盖与否对它影响小
实际建表时怎么避免踩坑
别只盯着“B+Tree”三个字，要盯住数据落盘方式：
- 高并发写入、需要事务或外键？必须用 InnoDB —— MyISAM 的表级锁在
UPDATE时会卡死整个表 - 纯静态报表表、大量
COUNT(*)或全表扫描？MyISAM 的.MYD是紧凑连续存储，COUNT 很快；InnoDB 得扫聚簇索引或依赖 MVCC 快照，更耗资源 - 想用
TEXT/BLOB字段做索引前缀？MyISAM 支持前缀索引长度到 1000 字符，InnoDB 默认限制 767 字节（innodb_large_prefix=ON且ROW_FORMAT=DYNAMIC才能突破） - 从 MyISAM 迁移到 InnoDB 时，检查所有二级索引字段组合：如果原来靠“多列索引覆盖”避免回表，迁过去后可能因主键过大反而让索引更占空间
真正难的不是理解 B+Tree 结构，而是意识到：同一个树形逻辑，在 InnoDB 里是“数据即索引”，在 MyISAM 里是“索引即地图”。选错引擎，优化 SQL 和加索引都救不回来。
