InnoDB在纯只读高并发场景下比MyISAM更稳更快，因其MVCC快照读不加锁、缓冲池精准管理热数据、聚簇索引减少IO次数，而MyISAM表级锁易被REPAIR/ANALYZE等操作阻塞，且依赖OS缓存、无并发控制能力。
纯只读场景下InnoDB比MyISAM快，不是玄学，是缓冲池、并发模型和查询路径共同作用的结果——尤其在真实部署环境中。
为什么InnoDB的SELECT在高并发下更稳
MyISAM的“读快”只存在于单线程、无竞争、数据全在OS缓存的理想状态；一旦并发上升，它的表级锁机制就会暴露：REPAIR TABLE、INSERT DELAYED、甚至ANALYZE TABLE都会触发全表写锁，阻塞所有后续SELECT。而InnoDB在READ COMMITTED或REPEATABLE READ下，普通SELECT走MVCC快照读，不加锁、不阻塞、不争抢MDL。
- MyISAM的
SELECT COUNT(*)虽快，但前提是表没被任何写操作干扰过；只要后台有ETL任务（哪怕只是INSERT INTO ... SELECT），就可能卡住整个查询队列 - InnoDB的
SELECT COUNT(*)确实要扫索引，但配合innodb_stats_method=sampled（MySQL 8.0+默认）后，采样估算耗时远低于MyISAM的全表扫描 - 从库启用
read_only=ON后，InnoDB能彻底杜绝误写，而MyISAM在复制中断后常因Can't find record错误导致SQL线程停摆
缓冲池让InnoDB的“热数据访问”更高效
MyISAM依赖操作系统页缓存，无法控制哪些数据该留、哪些该换；InnoDB的innodb_buffer_pool_size可精准覆盖热点行和索引页，且支持innodb_buffer_pool_dump_at_shutdown实现重启后秒级热加载。
- 新环境若未调大
innodb_buffer_pool_size，性能会掉——但这不是InnoDB的问题，是配置没跟上内存扩容 -
innodb_old_blocks_pct和innodb_old_blocks_time能防止批量导入把热页挤出缓存，MyISAM对此完全无感知 - 即使同样走磁盘IO，InnoDB的
innodb_read_io_threads和预读机制（innodb_read_ahead_threshold）对顺序扫描更友好
索引结构差异在真实查询中放大优势
MyISAM索引文件(.MYI)与数据文件(.MYD)分离，频繁随机读容易引发磁盘寻道争抢；InnoDB聚簇索引把主键和数据存在一起，主键等值查询一次B+树定位即完成，没有回表开销。
- 有主键的
SELECT * FROM t WHERE id = ?，InnoDB只需一次索引查找；MyISAM要先查.MYI拿到地址，再跳转到.MYD读数据，两次IO - 覆盖索引（如
SELECT status, updated_at FROM t WHERE user_id = ?）在InnoDB中效果更明显，因为二级索引叶子节点存的是主键值，体积小、缓存利用率高 - MyISAM的
KEY_BLOCK_SIZE不可调，InnoDB支持ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8，压缩后IO更低、缓存更省
最容易被忽略的一点：所谓“MyISAM读得快”，多数是建立在它长期没更新、统计信息陈旧、且没遭遇任何锁冲突的测试条件上；而真实报表库往往伴随定时ETL、夜间重算、监控探针轮询——这些行为在MyISAM上就是定时炸弹，在InnoDB里则被MVCC和行锁消化于无形。
