myisam在纯只读、高频聚合查询、低内存环境及冷备恢复快等场景下仍有优势，但需严格确认无任何写入操作，否则存在数据损坏风险；主从复制中innodb稳定性更高。
不划算，除非你同时在改写查询逻辑或引入事务一致性需求。
纯只读报表场景下MyISAM仍有合理存在空间
如果表完全只读（无任何INSERT/UPDATE/DELETE）、数据量稳定、且高频执行SELECT COUNT(*)、MIN()、MAX()这类聚合操作，MyISAM的元数据缓存机制确实带来更低延迟和更小内存开销。InnoDB每次COUNT(*)都要走索引扫描，哪怕没WHERE条件，性能差距在千万级行时可测出10%–30%。
- MyISAM的
.MYD/.MYI文件结构简单，冷备恢复快，适合归档类报表库 - InnoDB的
.ibd文件默认16KB起，空表也占空间；含TEXT/BLOB字段时页内碎片更明显，磁盘占用通常比MyISAM高20%–50% - MyISAM不依赖
innodb_buffer_pool_size，对内存敏感型部署更友好
切换前必须确认是否真“只读”
很多标称“只读”的报表库其实在后台跑定时ETL任务，比如INSERT INTO report_daily SELECT ... FROM source_table。这种批量写入一旦用MyISAM，中断后会留下部分写入的损坏状态；而InnoDB可回滚到事务起点——此时切换就不是“划不划算”，而是“敢不敢继续用”。
- 检查
SHOW PROCESSLIST中是否有长期运行的INSERT SELECT或REPLACE INTO - 查
information_schema.TABLES里UPDATE_TIME是否为空或长期未变 - 监控
Com_insert/Com_update等状态变量，看是否有非零增长
若决定切换，重点不是引擎，是查询重写
真正影响报表性能的往往不是引擎本身，而是WHERE条件是否命中索引、GROUP BY是否触发临时表、ORDER BY是否走索引排序。InnoDB对LIKE "%keyword"同样退化为全表扫描+行锁，和MyISAM行为一致，但MyISAM此时是表锁，反而可能更快（因无MVCC开销）。
- 避免直接迁移后沿用旧SQL：InnoDB的
key_buffer_size已无意义，必须调低，否则抢内存 - MyISAM支持
INSERT DELAYED，InnoDB不支持，需改用批量INSERT或应用层缓冲 - 全文检索若重度依赖
BOOLEAN MODE中的+/-运算符，MySQL 8.0的InnoDB仍不完全兼容，别硬切
最常被忽略的一点：报表库常被配置为从库，而MyISAM在主从复制中崩溃后可能中断SQL线程，InnoDB则能自动跳过损坏事件继续同步——这个稳定性收益，远比“COUNT(*)快几毫秒”重要得多。
