MyISAM在从库上无法稳定运行主从复制，因其DML操作不生成可靠binlog事件，导致复制报错如ERROR 1032/1594、数据不一致；其表级锁和无崩溃恢复机制在读写分离场景下反成性能瓶颈，而InnoDB配合合理配置与索引表现更优。
MyISAM在从库上根本无法稳定运行主从复制
MySQL主从复制依赖binlog重放，而MyISAM表的DML操作（如INSERT、UPDATE）不生成可靠的逻辑日志事件。主库若用InnoDB（99%生产环境如此），从库却用MyISAM，SHOW SLAVE STATUS会频繁报错：ERROR 1032 (HY000): Can't find record in 'xxx'或ERROR 1594 (HY000): Relay log read failure。这不是配置问题，是引擎层不兼容——binlog里没有MyISAM所需的行变更上下文，从库回放时直接找不到记录或跳过关键步骤。
常见错误现象包括：
- 从库复制线程
Slave_SQL_Running: No，且Last_SQL_Error反复出现上述错误 - 主从数据肉眼可见不一致（比如主库已删某条记录，从库仍存在）
-
REPAIR TABLE后短暂恢复，但下次写入又中断
所谓“MyISAM读快”在读写分离中基本不成立
MyISAM的“只读性能优势”只存在于单机、低并发、无索引竞争的玩具场景；而读写分离部署天然伴随多连接池、缓存穿透、复杂JOIN和分页查询。此时MyISAM的表级锁反而成瓶颈：哪怕只是SELECT COUNT(*) FROM user_status，一旦主库有INSERT DELAYED或从库执行OPTIMIZE TABLE，整张表就卡死。
InnoDB在同样负载下表现更稳：
- 启用
innodb_buffer_pool_size后，热数据页常驻内存，避免磁盘随机IO -
innodb_read_io_threads（MySQL 8.0+默认开启）可并行预读，吞吐更高 - 配合覆盖索引，
SELECT status, updated_at FROM user_status WHERE updated_at > '2026-09-01'这类查询，InnoDB QPS反超MyISAM 20%~40%
真正影响从库读性能的从来不是引擎，而是配置与SQL写法
把性能问题归咎于InnoDB，往往掩盖了更关键的缺陷：没建对索引、autocommit=1导致隐式事务开销、从库slave_parallel_workers设为0、或者业务代码里滥用SELECT COUNT(*)全表扫描。
实测对比（10万行用户状态表，TPS 500+）：
- MyISAM从库CPU常飙至95%，响应延迟毛刺明显
- InnoDB从库CPU稳定在60%以下，且
innodb_stats_method=sampled让COUNT(*)估算极快 - 加一个
INDEX(updated_at)后，InnoDB的WHERE查询延迟从80ms降到5ms，MyISAM无改善
如果真有纯静态读表，也别用MyISAM，换Archive或只读InnoDB
某些历史归档表、配置字典表确实极少更新。但MyISAM仍是坏选择：它不支持崩溃自动恢复，.MYI索引文件独立存放，高并发SELECT易引发磁盘争抢；而Archive引擎专为只读归档设计，压缩比高、IO压力小；或者干脆用InnoDB，设read_only=ON + innodb_flush_log_at_trx_commit=2，既安全又轻量。
容易被忽略的一点：MySQL 8.0+已移除MyISAM默认支持，新版本安装包甚至不带myisamchk工具——你今天能跑起来，不代表下周补丁升级后还能同步。
