先下个结论：MyISAM 将索引与数据分开存储，并非技术上的失误，而是一种清晰且轻量化的设计哲学——它从设计之初就没有打算支持事务、行锁或崩溃恢复，因此完全没有必要将数据与索引强制绑定在一起。 ## MyISAM 的文件架构：各管各的 这种分离最直观的体现，就是文件各自承担独立的职责： - `.MYI` 文件仅存放 B+Tree 索引结构，其叶子节点中存储的不是数据行本身，而是一个磁盘地址指针（例如 `0x1A2B3C` 这样的偏移量） - `.MYD` 文件则是一个纯粹的堆表，数据按插入顺序线性写入，既不排序，也不聚簇，更不维护任何逻辑顺序 执行一条 `SELECT * FROM t WHERE id = 123` 时，实际流程如下：先读取 `.MYI` 找到对应的地址指针，再跳转到 `.MYD` 读取那一行数据——这一过程涉及两次独立的磁盘 I/O。 但如果执行 `SELECT * FROM t` 做全表扫描，情况则完全不同：引擎会完全绕过 `.MYI`，直接顺序读取 `.MYD` 文件，因此速度非常快。 ## 那为什么不像 InnoDB 那样，直接把数据塞进索引叶子节点？ InnoDB 之所以必须采用聚簇索引，是因为它需要依靠主键来组织物理存储，进而支撑 MVCC、行锁和崩溃恢复机制。而 MyISAM 没有这些额外负担： - 不支持事务 → 自然无需 `undo log` 和 `redo log`，也就不依赖“主键⇔物理位置”的强绑定关系 - 只支持表锁 → 加锁对象是整个 `.MYD` 文件，无需按主键精确定位某一行 - 崩溃后无法安全恢复 → 一旦 `.MYI` 损坏，只能通过 `REPAIR TABLE` 尝试修复，没有任何机制能重建地址映射 因此 MyISAM 选择了最直接的路径：索引归索引，数据归数据，各自独立更新，逻辑清晰且实现简单。 ## 换一个角度看：分离结构隐藏的实际代价 当写入操作增多或并发量上升时，这种分离结构的缺陷就暴露无遗： - 每次 `UPDATE` 或 `DELETE` 都需要同时修改 `.MYI` 和 `.MYD`，两个文件可能落在不同的磁盘块上，随机 I/O 自然随之增加 - `INSERT` 操作会锁定整个 `.MYD` 文件，导致其他读写全部被阻塞 - `OPTIMIZE TABLE` 本质上是在重建两个文件，过程中表不可写，且临时空间会急剧膨胀 更值得关注的是：MyISAM 并不支持覆盖索引优化。即使你写 `SELECT name FROM t WHERE email = 'x@y'`，并且 `(email, name)` 上建有联合索引，它仍然需要回 `.MYD` 去取数据——因为索引叶子节点里只有地址，没有存储任何列值。 这种“地址即一切”的模型，划定了 MyISAM 的能力边界：它适合读多写少、能接受表锁、且能容忍修复失败风险的场景。一旦写入压力增大，或者业务对数据一致性有强要求，这种分离结构便不再是特色，而是实实在在的硬伤。