MyISAM在从库上无法可靠回放binlog，因其不支持事务和崩溃安全机制，导致SQL线程频繁中断、隐性延迟加剧、并行复制失效，且无法满足读写分离生产需求。
MyISAM在从库上无法可靠回放binlog
MySQL主从复制依赖于binlog重放，而MyISAM引擎不支持事务和崩溃安全的binlog写入机制。当主库使用InnoDB（绝大多数生产环境），从库误配为MyISAM时，SHOW SLAVE STATUS会频繁报错：ERROR 1032 (HY000): Can't find record in 'xxx' 或 ERROR 1594 (HY000): Relay log read failure。这些错误导致SQL线程中断、重试、跳过或卡死，直接表现为Seconds_Behind_Master持续飙升甚至停滞。
MyISAM表级锁阻塞从库SQL线程回放
即使复制暂时没报错，MyISAM的表级锁也会在从库引发隐性延迟：
- 从库执行
ANALYZE TABLE或OPTIMIZE TABLE时，会持MDL写锁，阻塞所有后续SQL线程的回放 - 高并发SELECT虽不加锁，但一旦有
INSERT DELAYED或REPAIR TABLE触发，整张表冻结，SQL线程只能等待 - 从库若同时承担报表查询，MyISAM频繁随机IO（
.MYI索引独立存储）进一步拖慢磁盘响应，加剧SQL线程IO等待
MyISAM缺乏并行复制支持能力
MySQL 5.7+的基于组提交的并行复制（MTS）要求引擎支持事务一致性边界识别。MyISAM无事务、无redo、无XA prepare阶段，无法参与slave_parallel_type=LOGICAL_CLOCK的调度逻辑。结果就是：哪怕开启多线程复制，SQL线程仍被迫退化为单线程串行回放，大事务场景下延迟秒变分钟级。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
所谓“MyISAM读快”在读写分离中根本不可用
真实读写分离场景下，MyISAM的“优势”完全失效：
- 它无法与InnoDB主库长期稳定同步——复制中断是常态，不是例外
- 它的“快”只存在于单线程、无并发、无索引竞争的玩具测试中；生产环境QPS一上来，CPU就飙到95%+
- 它不支持
read_only=ON的真正防护（SUPER权限用户仍可写），从库误写后主从数据彻底错乱，修复成本远高于延迟本身
真正该调优的是InnoDB：比如从库设innodb_flush_log_at_trx_commit=2、用ROW_FORMAT=COMPRESSED压表、关掉innodb_stats_on_metadata——这些操作才实际降低回放开销。MyISAM不是解药，是埋雷。
