myisam仅在无条件count(*)等特定场景下比innodb快，因其缓存行数；主键等值查询innodb更快（聚簇索引）；myisam表级锁并发差、无崩溃恢复，可靠性低。
MyISAM在某些特定查询场景下确实比InnoDB快，但这不是普遍结论，而是由底层机制差异和测试条件共同决定的——关键看查什么、怎么查、数据是否带索引、事务隔离级别是否介入。
MyISAM的COUNT(*)为什么快得明显
MyISAM在表结构中直接维护了行数计数器，执行SELECT COUNT(*) FROM table时无需扫描数据文件，直接返回缓存值。InnoDB则必须遍历聚簇索引（或优化路径下的二级索引）统计行数，尤其在大表且无WHERE条件时差距可达百倍。
- 这个优势只对无条件
COUNT(*)有效；一旦加上WHERE，两者都需走索引或全表扫描，MyISAM不再有“计数缓存”红利 - InnoDB在MySQL 8.0+中对
COUNT(*)做了部分优化（如利用采样估算），但默认仍不缓存精确值 - 如果业务真依赖高频
COUNT(*)，更稳妥的做法是用单独的计数表或Redis缓存，而非迁移到MyISAM
主键等值查询时InnoDB其实不慢，甚至更快
当查询条件命中主键（如SELECT * FROM t WHERE id = 123），InnoDB的聚簇索引让数据和索引在同一页内，一次B+树查找即可定位并读取整行；MyISAM需先查索引文件拿到偏移量，再跳转到数据文件读取，多一次I/O寻址。
- 实测百万级主键查询，InnoDB通常比MyISAM快10%–30%，尤其在SSD或buffer pool充足时
- MyISAM的非聚簇索引在范围查询（如
id BETWEEN 1000 AND 2000）中可能略优，但InnoDB通过自适应哈希索引（AHI）和预读机制可大幅缩小差距 - 如果MyISAM查询慢，大概率是因为
.MYI索引文件碎片化严重，需定期OPTIMIZE TABLE
并发查询下MyISAM的“快”会迅速崩塌
MyISAM的表级锁意味着：一个SELECT正在执行时，后续所有INSERT/UPDATE/DELETE都会排队等待；反之亦然。而InnoDB的行级锁允许读写并行，只要不冲突，多个查询可同时进行。
- 单线程压测下MyISAM看起来快，但真实业务是混合负载——只要并发写入一上来，MyISAM的查询延迟就会剧烈抖动
- MyISAM在高并发
SELECT时虽不互斥，但若某条查询触发了REPAIR TABLE或ALTER TABLE，整个表立即不可读 - InnoDB的MVCC机制让
SELECT几乎不加锁（除SELECT ... FOR UPDATE），读性能更稳定，尤其适合长连接+短查询场景
真正影响大数据量查询速度的，往往是配置和写法
很多所谓“MyISAM更快”的测试，实际掩盖了InnoDB未调优的事实。比如默认innodb_buffer_pool_size太小，导致频繁磁盘换页；或没建好覆盖索引，让InnoDB被迫回表。
- 确保
innodb_buffer_pool_size设为物理内存的50%–75%，否则InnoDB连热数据都装不下 - 对高频查询字段组合建联合索引，避免
Using filesort和Using temporary - 分页慎用
LIMIT offset, size，无论MyISAM还是InnoDB，offset越大越慢；改用游标式分页（如WHERE id > last_id ORDER BY id LIMIT 20） - MyISAM的
DELAY_KEY_WRITE=1能加速索引更新，但崩溃后索引可能损坏，线上禁用
真正容易被忽略的是：MyISAM没有崩溃恢复能力，一次意外断电可能导致索引与数据不一致，后续所有查询结果都不可信——这种“快”，是以数据可靠性为代价的。而InnoDB的慢，常常慢在你没让它按批量、有序、无约束的方式工作，而不是引擎本身不行。
