MyISAM已过时且不适用于只读报表场景：MySQL 8.0+全面弃用，复制不可靠、统计不准、锁表阻塞，InnoDB在真实负载下只读性能更优，配置优化远胜引擎替换。
没必要，而且风险远大于收益。 即使是纯只读报表场景，MyISAM 也不再是合理选择——MySQL 8.0+ 已全面弃用它，且其所谓“读快”优势在真实部署中几乎不存在，反而会引入复制中断、统计不准、锁表阻塞等实际问题。
MyISAM 在只读从库上根本跑不稳
主库用 InnoDB（99% 的情况）时，MyISAM 表无法被可靠复制：binlog 中的 ROW 格式事件无法映射到 MyISAM 表结构，SHOW SLAVE STATUS 常见报错包括 ERROR 1032 (HY000): Can't find record in 'xxx' 和 ERROR 1594 (HY000): Relay log read failure。强行启用会导致从库数据静默错乱，且无法通过 REPAIR TABLE 恢复一致性。
- MySQL 官方自 5.5 起默认引擎就是 InnoDB，8.0 系统表已全部迁移至 InnoDB，MyISAM 仅保留兼容层，无新功能、无 bug 修复
- 即使你手动把从库表转成 MyISAM，只要主库有 DDL（如
ALTER TABLE），复制立刻中断 -
read_only=ON对 MyISAM 无效：它不阻止INSERT DELAYED或LOAD DATA INFILE，这些操作会直接破坏只读语义
InnoDB 的只读性能已被严重低估
MyISAM 所谓“COUNT(*) 快”仅在空缓存、单线程、无并发的玩具场景成立；真实报表系统面对的是连接池复用、缓存穿透、多维聚合查询，此时 InnoDB 的优势才真正显现：
-
innodb_stats_method=sampled让COUNT(*)不再全表扫描，比 MyISAM 的元数据计数更准、更快（尤其带WHERE条件时） - 覆盖索引 +
innodb_buffer_pool_size配置合理，热数据页常驻内存，IO 压力远低于 MyISAM 的分离式.MYD/.MYI文件随机访问 - 从库关闭
innodb_flush_log_at_trx_commit=2和sync_binlog=0后，纯读负载下 QPS 反超 MyISAM 20%~40%，CPU 利用率更低
真正该调的不是引擎，而是 InnoDB 的只读适配项
与其花时间迁移引擎，不如确认这几项配置是否生效：
- 从库必须设
read_only=ON，并配合权限控制（禁用SUPER权限账号写入） - 禁用
ANALYZE TABLE和OPTIMIZE TABLE：它们会触发 MDL 写锁，让所有 SELECT 卡住 - 大历史表（如订单归档）启用
ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8，压缩率 40% 且仍支持索引和事务安全 - 避免在从库执行
SELECT ... FOR UPDATE或任何显式加锁语句——InnoDB 会照常上锁，哪怕read_only=ON
MyISAM 是个过时的幻觉。现在连 mysqldump --single-transaction 都默认跳过 MyISAM 表，因为它的快照一致性无法保障。别为了一点纸面数字，把生产环境拖进复制断裂、统计失真、运维不可控的坑里。
