MyISAM不是读写分离架构下的更优选择，因其不支持可靠主从复制、表级锁制约高并发读、随机IO性能差，且实际QPS常低于调优后的InnoDB。
读写分离架构下，MyISAM不是更优选择
读写分离本身不改变存储引擎的底层行为——主库写、从库读，但引擎特性决定数据一致性、恢复能力与锁行为是否可控。MyISAM在从库上看似“读得快”，可一旦主库用的是InnoDB（绝大多数情况），就根本没法做主从复制：MySQL原生复制只支持基于binlog的逻辑日志，而MyISAM表的变更无法被可靠捕获并重放，SHOW SLAVE STATUS会频繁报ERROR 1032 (HY000): Can't find record in 'xxx'或ERROR 1594 (HY000): Relay log read failure。强行混用会导致从库数据错乱、复制中断，且事务回滚后MyISAM表状态不可逆。
MyISAM所谓“只读性能优势”在真实读写分离中基本不存在
MyISAM的读取优势仅出现在单机、无并发、无索引竞争的简单场景下；而读写分离部署必然伴随高并发查询、多连接池、缓存穿透等压力。此时MyISAM的表级锁反而成为瓶颈：SELECT语句虽不加写锁，但一旦有INSERT DELAYED或REPAIR TABLE执行，整张表就卡住。InnoDB在READ COMMITTED或REPEATABLE READ隔离级别下，配合覆盖索引和合理缓冲池配置，QPS通常反超MyISAM 20%~40%。实测中，10万行用户状态表（含status、updated_at字段）在TPS 500+时，MyISAM从库CPU常飙至95%，InnoDB稳定在60%以下。
- MyISAM的
.MYI索引文件是独立存放的，频繁SELECT易引发磁盘随机IO争抢 - InnoDB的聚集索引让主键查询天然高效，且
innodb_buffer_pool_size可缓存热数据页，大幅降低IO - MySQL 8.0+默认启用
innodb_read_io_threads和innodb_read_ahead_threshold，进一步优化读密集负载
真正该关注的是InnoDB如何适配读写分离
选InnoDB不是终点，而是起点。关键配置必须调优，否则读性能照样拉胯：
- 从库务必设置
read_only=ON，防止误写导致主从不一致；但注意它不阻拦SUPER权限用户，需配合账号权限控制 - 关闭从库的
innodb_flush_log_at_trx_commit=2和sync_binlog=0（仅限非金融类业务），减少刷盘开销 - 对纯查询大表（如订单历史），考虑
ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8，压缩率可达40%，比MyISAM压缩表更安全、可索引 - 避免在从库执行
ANALYZE TABLE或OPTIMIZE TABLE——这些操作会触发MDL写锁，阻塞所有查询
别迷信“MyISAM读快”的旧经验。现在连SELECT COUNT(*)这种操作，InnoDB通过采样估算（innodb_stats_method=sampled）也比MyISAM全表扫描快得多。真正拖慢读性能的，往往是没建对索引、没关掉autocommit、或者从库延迟积压，而不是引擎本身。
