innodb聚簇索引使主键查询更高效：因数据与主键索引共存于b+树叶子节点，一次遍历即得全部字段；而myisam索引叶节点仅存磁盘偏移量，需二次i/o读取数据。
InnoDB 的聚簇索引在主键查询、范围扫描、高并发读写混合场景下通常比 MyISAM 更快，但这不是绝对的——它取决于你查什么、怎么查、数据怎么组织。
真正决定“谁更快”的，从来不是引擎名字，而是底层数据组织方式与你的查询模式是否匹配。
聚簇索引如何让主键查询更高效
InnoDB 把主键索引和实际行数据存在同一个 B+Tree 的叶子节点里。查主键时，一次树遍历就拿到全部字段，没有额外跳转。
MyISAM 的主键索引（或任何索引）叶子节点只存磁盘偏移量（.MYD 文件中的 offset），必须再做一次文件读取才能拿到数据——这多了一次 I/O 定位开销。
- 主键等值查询（
WHERE id = ?）：InnoDB 通常比 MyISAM 快 10%–30%，尤其当表大、缓存未命中时差异更明显 - 主键范围查询（
WHERE id BETWEEN ? AND ?）：InnoDB 叶子节点物理连续，顺序读页效率高；MyISAM 的数据散落在.MYD中，容易产生随机 I/O - 如果主键是自增整型，InnoDB 的插入也几乎不引起页分裂，B+Tree 结构更紧凑
为什么非主键查询反而可能变慢
当你用非主键字段（比如 email 或 name）查数据，InnoDB 要走两步：先查辅助索引树拿到主键值，再回主键索引树查整行——这就是「回表」。
MyISAM 没有回表概念：它的所有索引（包括辅助索引）叶子节点都直接指向 .MYD 中的数据地址，一次定位即可。
- 辅助索引覆盖查询（
SELECT email FROM t WHERE name = ?）：MyISAM 常胜，因为不需要读行数据 - 辅助索引 + 回表（
SELECT * FROM t WHERE name = ?）：InnoDB 多一次 B+Tree 查找，若主键过长（如用 UUID），辅助索引体积也大，性能进一步被拖累 - MyISAM 在这种场景下常快 20%–50%，尤其当表行数多、缓冲池不够大时
并发读写对查询延迟的实际影响
很多人忽略一点：InnoDB 的「慢」往往不是查询本身慢，而是被锁或 MVCC 版本检查拖住。
例如一个长事务没提交，后续所有 SELECT 都得检查每一行的隐藏版本号（DB_TRX_ID 和 DB_ROLL_PTR），确认该行对当前事务是否可见——这个判断在每行上都要做。
- MyISAM 没有 MVCC，也不维护事务状态，
SELECT几乎不检查任何元数据 - 但代价是：只要有一个
UPDATE正在执行，整个表就不可读（表锁），而 InnoDB 允许多个SELECT并发进行 - 所以单线程压测时 MyISAM 可能赢；真实业务中若有写入混杂，InnoDB 的平均查询延迟反而更稳
缓存机制差异导致的冷启动表现不同
InnoDB 缓存的是「数据页 + 索引页」，MyISAM 默认只缓存「索引页」（key_buffer_size），数据靠操作系统页缓存。
- 刚重启后首次查询：MyISAM 如果索引全在内存，但数据不在，就得触发磁盘读；InnoDB 若 buffer pool 不够，也要读磁盘，但至少索引和数据在同一页里，局部性更好
- 大表全表扫描：InnoDB 的聚簇结构让顺序读更接近物理连续，OS 预读更有效；MyISAM 的
.MYD是堆组织，记录插入顺序混乱，预读收益低 -
innodb_buffer_pool_size设置过小（比如低于总数据量 50%）时，InnoDB 性能断崖式下跌；而 MyISAM 对key_buffer_size不敏感，只要索引不大，就能维持不错响应
真正容易被忽略的点是：聚簇索引的优势只在主键路径上成立；一旦脱离主键，InnoDB 就要付出额外成本，而 MyISAM 保持恒定开销。选引擎前，先看你的 WHERE 条件是否高频命中主键，以及是否允许写操作阻塞全表读。
