MyISAM在纯读密集场景下“看似”更快，实为牺牲一致性换来的假象；其无事务、表锁、索引分离等特性仅在小表低并发测试中占优，真实业务中因不支持事务、崩溃恢复不可靠、写阻塞读等缺陷而不可用。
MyISAM 在纯读密集型场景下“看似”更快，是因为它没有事务开销、无行锁机制、结构简单、索引缓存更轻量——但这只是表象，不是推荐方案。
真正该做的是让 InnoDB 发挥读性能，而不是倒退到 MyISAM。
为什么 MyISAM 的 SELECT 看起来快？
MyISAM 的查询快，本质是靠牺牲一致性换来的：
- 不支持事务，跳过 MVCC 版本判断、undo 日志查找等步骤；
- 表级锁（READ LOCK）下多个读并发不互斥，但写一来就全卡住；
- 索引文件（.MYI）和数据文件（.MYD）分离，key_buffer_size 只缓存索引，配合 OS page cache 缓存数据，内存占用低；
- 没有聚簇索引，主键和二级索引结构一致，回表就是一次额外的随机读（但对小表影响小）。
这些在只读、静态、小表、低并发的测试环境里容易跑出高 QPS，但一进真实业务就露馅。
MyISAM 在读密集型场景下的致命缺陷
-
ALTER TABLE、OPTIMIZE TABLE期间整个表不可读 —— 对“读密集”来说等于雪崩式中断 - 崩溃后无法保证数据一致性，
REPAIR TABLE可能丢数据，且耗时不可控 - 不支持外键、在线 DDL、全文索引（5.6+ InnoDB 已支持），运维成本陡增
- 一旦有哪怕一个写请求（比如统计计数更新），所有读都会被阻塞，热点表极易排队
-
key_buffer_size只缓索引，数据仍依赖 OS cache，大表下缓存命中率低，I/O 压力没减少
真正有效的读密集优化：聚焦 InnoDB 缓冲池与访问模式
别碰 MyISAM，把精力放在让 InnoDB 更懂你的读：
- 把
innodb_buffer_pool_size设为物理内存的 70%~80%，确保热点数据页常驻内存 —— 这比换引擎管用十倍 - 用
SELECT ... FOR SHARE替代SELECT显式声明读意图，避免被意外升级为写锁 - 确认查询是否走覆盖索引：用
EXPLAIN看Extra列是否含Using index，避免回表放大 I/O - 关闭
query_cache_type=0（MySQL 8.0 已移除），旧版开启反而因失效风暴拖慢读性能 - 对超大只读表（如日志归档表），可考虑
innodb_read_only=1+innodb_flush_log_at_trx_commit=2组合，降低刷盘压力
什么时候真该考虑 MyISAM？
几乎不需要。唯一勉强成立的场景：
- 数据完全静态（上线后永不变更）
- 表极小（
- 查询极其简单（单字段等值、无 JOIN、无排序）
- 运维团队明确接受“坏了就重导”的兜底策略
现实中，这类表早该进 Redis 或本地缓存，而不是塞进 MySQL 里靠引擎取巧。InnoDB 的读能力天花板远高于 MyISAM，只是需要配得对、查得准、缓得稳——而这些，恰恰是最容易被跳过的细节。
