innodb主键查询通常更快，因其聚簇索引将主键与数据存于同一b+树叶子节点，一次i/o即可获取全部字段；myisam非聚簇索引需先查索引再读数据文件，额外i/o导致主键等值或范围查询更慢。
InnoDB 和 MyISAM 查询性能没有绝对优劣，快慢取决于你查什么字段、用什么条件、是否并发写入、缓存是否预热——不是引擎名字决定的，是数据组织方式和查询模式是否匹配。
主键等值或范围查询时，InnoDB 通常更快
因为 InnoDB 的聚簇索引把主键和整行数据存在同一个 B+Tree 叶子节点里，一次磁盘定位就能拿到全部字段；MyISAM 的索引叶节点只存 .MYD 文件中的偏移量，必须额外做一次 I/O 才能读到数据。
- 主键等值查询（
WHERE id = ?）：InnoDB 平均快 10%–30%，尤其在大表、冷缓存下更明显 - 主键范围扫描（
WHERE id BETWEEN 10000 AND 20000）：InnoDB 叶子节点物理连续，顺序读页效率高；MyISAM 数据散落在.MYD中，容易触发随机 I/O - 自增主键插入场景：InnoDB 页分裂少，B+Tree 更紧凑，间接提升后续主键查询的缓存命中率
非主键字段查询时，MyISAM 常常更快
当你用辅助索引查数据（比如 WHERE name = 'xxx'），InnoDB 必须先查辅助索引拿到主键值，再回主键索引树查整行——这就是「回表」；MyISAM 所有索引叶子节点都直接指向数据地址，一次定位完事。
-
SELECT email FROM t WHERE name = ?：MyISAM 不需要读行数据，优势明显 -
SELECT * FROM t WHERE name = ?：InnoDB 多一次 B+Tree 查找，若主键是UUID这类长字段，辅助索引体积更大，回表成本更高 - 真实测试中，这种场景 MyISAM 常比 InnoDB 快 20%–50%，尤其当 Buffer Pool 不够大、频繁换页时
并发写入混杂时，InnoDB 的平均延迟更稳
单线程压测下 MyISAM 可能赢，但真实业务里只要有一条 UPDATE 正在执行，MyISAM 就会锁整张表，所有 SELECT 都得排队；InnoDB 虽然要检查每行的 DB_TRX_ID 和 DB_ROLL_PTR 来判断可见性（MVCC 开销），但它允许读写并发。
- 长事务未提交时，InnoDB 的 SELECT 会变慢，但这不是索引结构问题，而是版本可见性检查开销
- MyISAM 没 MVCC，SELECT 几乎不检查元数据，但代价是写操作期间整个表不可读
- QPS 高、读写混合的 OLTP 场景下，InnoDB 的 p95 延迟通常更可控
冷启动和缓存机制差异影响实际表现
刚重启 MySQL 后第一次查询，性能差距会被放大：InnoDB 缓存的是「数据页 + 索引页」，MyISAM 默认只缓存「索引页」（key_buffer_size），数据仍要从磁盘读取。这意味着：
- MyISAM 主键查询在冷启动时可能比 InnoDB 慢得多——它得读两次磁盘（索引 + 数据）
- InnoDB 的
innodb_buffer_pool_size如果没配够，大量页换入换出，回表操作会雪上加霜 - MyISAM 的
COUNT(*)之所以快，是因为它维护了行数计数器，但这仅对无 WHERE 条件生效；一旦加条件，两者都要扫数据
真正容易被忽略的点是：你看到的“慢”，常常不是引擎本身慢，而是你没意识到自己正在触发回表、MVCC 版本遍历，或者缓存根本没覆盖到热点数据页。选引擎前，先用 EXPLAIN 看执行计划，确认走的是主键还是辅助索引，再结合业务读写比例和一致性要求做判断。
