InnoDB主键索引B+树叶节点存整行数据，MyISAM存行号或文件偏移量；前者聚簇索引支持高效回表与局部性访问，后者索引数据分离导致随机IO多、缓存差、锁粒度粗。
千万级数据下InnoDB和MyISAM的B+树叶子节点存什么
核心区别就一句话：InnoDB主键索引的B+树叶节点存的是整行数据，MyISAM的B+树叶节点存的是行号或文件偏移量（即指向.myd数据文件的地址）。这直接导致查询路径长度、IO次数、回表行为完全不同。
比如执行SELECT * FROM t WHERE id = 123（id为主键）：
- InnoDB：一次B+树搜索直达数据，无需额外IO
- MyISAM：先查B+树拿到行号 → 再按行号跳转到
.myd文件读数据，固定2次IO
千万级数据时，这个“多一次随机IO”在机械盘上可能就是几十毫秒差异；即使SSD，页缓存压力也更大——MyISAM的索引和数据分离结构天然放大了缓存失效概率。
为什么InnoDB的B+树更适合高并发写入
因为InnoDB的聚簇索引强制数据按主键物理有序，而B+树所有数据集中在叶子节点且用双向链表连接，插入新记录时只要定位到对应叶子页，追加或分裂即可。MyISAM没有聚簇特性，新记录总是追加到.myd末尾，但索引树仍需更新指针，且.myi和.myd是两个独立文件，写入无法合并为原子操作。
常见错误现象：INSERT变慢、SHOW PROCESSLIST里大量Waiting for table flush，往往就是MyISAM在千万级数据下因文件锁粒度粗（表级锁）+ 索引/数据双写引发的争抢。
关键点：
- InnoDB的页大小默认
16KB，B+树非叶节点只存主键+指针，单页能容纳更多key，树高更低（千万数据通常3层） - MyISAM的
.myi页也存key，但每个索引项还要额外存row number，实际key密度更低，同等数据量树更高 - InnoDB的自适应哈希索引（AHI）是后台自动构建的，仅加速等值查询；MyISAM压根不支持哈希索引
千万级数据下普通索引的回表开销差异
假设对name建了普通索引，执行SELECT * FROM t WHERE name = 'Alice'：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- InnoDB：先查
name辅助索引树，拿到主键值（比如id=5001）→ 再查主键B+树定位整行（回表） - MyISAM：查
name索引树，直接拿到行号→ 跳转.myd读整行（不叫回表，叫“地址寻址”）
表面看都是2次IO，但本质不同：
— InnoDB的主键B+树本身已按主键排序，若查询涉及范围（如name BETWEEN 'A' AND 'C'），辅助索引叶子链表能高效扫描，再批量回表，缓冲池局部性好；
— MyISAM的行号是追加顺序，name索引查出的行号完全随机，导致.myd读取变成大量随机IO，缓冲池命中率断崖式下跌。
这也是为什么千万级MyISAM表做ORDER BY name或GROUP BY name极易触发Using filesort或Using temporary，而InnoDB配合覆盖索引（SELECT id,name FROM t WHERE name=...）可完全避免磁盘临时表。
别忽略数据文件组织方式对备份与恢复的影响
InnoDB所有数据（表结构除外）默认落在ibdata1或独立.ibd文件里，B+树节点和真实数据页是统一管理的；MyISAM则严格三分：表定义.frm、索引.myi、数据.myd。这意味着：
- 千万级MyISAM表
OPTIMIZE TABLE会锁表+全量复制数据文件，期间写入完全阻塞 - InnoDB的
ALTER TABLE ... ALGORITHM=INPLACE可在线重建索引，B+树分裂/合并由引擎内部控制，不影响DML - mysqldump恢复MyISAM千万级表时，
.myd文件顺序写入快，但.myi索引重建阶段CPU和IO飙升，容易超时；InnoDB恢复更平稳，因B+树是逐步填充的
真正容易被忽略的是：MyISAM的.myi文件损坏后，索引全丢，但.myd数据还在；InnoDB的B+树节点损坏往往连带数据页损坏，恢复必须依赖redolog和doublewrite buffer——设计上就决定了它不能省略这些机制。
