MyISAM仅在无WHERE的COUNT(*)、主键等值查询、全表扫描等极简场景下略快，但依赖脆弱条件且易损坏；InnoDB通过合理调优（如增大buffer pool、调整刷盘策略）可全面超越，且具备崩溃恢复与高可靠性。
不是绝对快，而是「在特定条件、特定查询、无并发写入干扰时，MyISAM 可能快一点」——但这个“快”往往被高估，且代价远高于收益。
MyISAM 的所谓“快”只在极简场景下成立
它的优势集中在三类操作上：COUNT(*)（无 WHERE）、主键等值查询（SELECT ... WHERE id = ?）、全表扫描（SELECT *）。原因很直接：没有事务开销、不维护 MVCC 版本信息、索引与数据分离、MyISAM 会缓存表行数。一旦加了复杂 WHERE、JOIN、ORDER BY 或者有并发写入，InnoDB 的聚簇索引和缓冲池（innodb_buffer_pool_size）很快就能扳回甚至反超。
- 比如
COUNT(*)：MyISAM 直接读元数据；InnoDB 必须扫聚簇索引或走二级索引 + 回表，但加了WHERE后两者都要执行实际扫描，差距消失 - 主键查询：InnoDB 聚簇索引把数据和主键放一起，一次 B+ 树定位就拿到整行；MyISAM 需先查索引文件，再按指针去数据文件读，多一次 I/O —— 实测中 InnoDB 常更快
- 非主键查询（如
WHERE status = 'done'）：如果建了二级索引，InnoDB 的二级索引叶子节点存的是主键值，需回表；MyISAM 的二级索引叶子存的是行物理偏移，看似少一层跳转，但实际受磁盘寻道和缓存影响更大
InnoDB 在读多场景下被低估的优化空间
很多人拿默认配置的 InnoDB 和 MyISAM 比，这不公平。InnoDB 的读性能高度依赖调优，而 MyISAM 几乎没得调。
-
innodb_buffer_pool_size至少设为物理内存的 70%：它缓存的是聚簇索引页 + 二级索引页 + 数据页，MyISAM 的key_buffer_size只缓索引，数据还得靠 OS page cache - 关闭
innodb_flush_log_at_trx_commit=2（仅适用于允许短暂丢失最后 1 秒事务的读多场景）：大幅降低 redo log 刷盘频率 - 用自增整型主键，避免 UUID 或字符串主键导致的页分裂和随机 I/O —— 这点对读性能也有间接提升
- 开启
innodb_read_io_threads（如设为 8），尤其在 SSD 上能更好压满 I/O 并发能力
MyISAM 表损坏不是小概率事件，而是必然发生
只要服务器异常重启、MySQL crash、kill -9 进程，MyISAM 表就有极高概率损坏。修复命令 REPAIR TABLE 不保证成功，且修复期间表锁死，无法读取。而 InnoDB 的崩溃恢复由 redo log 自动完成，通常秒级上线。
- 损坏表现包括：
Table is marked as crashed and should be repaired、Incorrect key file for table、查询返回空结果或乱码 - 即使日常运行中，MyISAM 的
CONCURRENT INSERT机制在有 DELETE 时也会失效，退化为表锁 - 官方从 MySQL 8.0 开始已彻底移除 MyISAM 的部分功能支持（如全文索引的某些特性），新版本兼容性持续恶化
真正需要考虑 MyISAM 的场景几乎不存在了——除非你维护一个十多年没升级的老系统，且确认从未发生过宕机、所有写入都是批量导入、且不介意某天凌晨三点被报警叫起来修表。否则，InnoDB 的“稍慢”是可控的，MyISAM 的“快”是脆弱的、不可靠的、且越来越难运维的。
