不划算，且存在严重风险；MyISAM在从库中无法正确回放ROW格式binlog，易导致复制中断、数据错位，而InnoDB能通过事务回滚保障一致性，运维更安全可控。
没有必要，且存在严重风险。MyISAM在只读从库中节省的内存（主要来自不依赖 innodb_buffer_pool_size）远低于它带来的复制中断、数据错位和运维不可控成本。
MyISAM在从库上根本无法稳定参与主从复制
主库用 InnoDB + binlog_format=ROW 是当前生产环境标配，而 MyISAM 表无法正确回放 ROW 格式的 binlog 事件。一旦从库有表被改成 MyISAM：
- 复制线程会静默卡在
ERROR 1594 (HY000): Relay log read failure或ERROR 1032 (HY000): Can't find record in 'xxx'，Seconds_Behind_Master失真 - 即使没报错，部分 DML 变更可能被跳过或应用失败，导致从库数据与主库逻辑不一致
-
SHOW SLAVE STATUS看似正常，但数据已悄然偏移——这种问题往往在报表对账时才暴露
所谓“省内存”在真实部署中几乎不成立
MyISAM 的 key_buffer_size 确实只缓存索引，不占数据页内存，但这是以牺牲查询效率为代价的：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 报表查询常需读取大量字段，
.MYD文件频繁触发随机 IO，CPU 和磁盘延迟反而更高 - 对比调优后的
innodb_buffer_pool_size（例如设为物理内存 70%），InnoDB 能缓存热数据页，QPS 通常反超 MyISAM 20%~40% - MySQL 8.0+ 支持
innodb_read_io_threads和ROW_FORMAT=COMPRESSED，压缩表可降低 40% 磁盘占用，且仍支持索引和事务一致性
真正安全的只读优化不在引擎层，而在配置与分层
如果你的目标是降低从库资源压力，应优先做这些事：
- 从库设置
read_only=ON+ 严格限制账号权限（禁用 SUPER），防止误写 - 关闭非关键刷盘：从库可设
innodb_flush_log_at_trx_commit=2和sync_binlog=0（非金融类业务） - 把大宽表、历史归档迁出 MySQL：用 ClickHouse / Doris 做聚合查询，MySQL 从库只留轻量维度表
- 若必须压磁盘空间，用
ALTER TABLE ... ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8，而非切 MyISAM
最常被忽略的一点：MyISAM 的“只读”是假定层面的，不是系统保障的。哪怕你确认当前没写入，只要未来某次 ETL 脚本漏掉判断、或 DBA 手动执行了 INSERT INTO ... SELECT，就会立刻破坏一致性——而 InnoDB 在这类场景下能靠事务回滚兜底。这不是性能权衡，是底线问题。
