MyISAM表导致SQL线程中断的根本原因是其不支持事务、无行级锁且不兼容ROW格式binlog重放；主库以ROW/MIXED格式记录变更时，从库SQL线程执行基于行的更新会直接报错“binlogging impossible”，并停止复制。
MyISAM表导致SQL线程中断的底层原因
MySQL从库SQL线程在回放Relay Log时，对MyISAM表的操作极易失败，根本不在配置或网络层面，而在存储引擎自身限制：MyISAM不支持事务、无行级锁、不兼容ROW格式binlog事件重放。当主库以MIXED或ROW格式记录变更（MySQL 5.7+默认），从库SQL线程尝试用MyISAM引擎执行基于行的更新/删除时，会直接报错Cannot execute statement: binlogging impossible since the storage engine of table ... does not support it，并停在Slave_SQL_Running: No状态。
STATEMENT格式也不能真正“绕过”问题
即使主库binlog_format=STATEMENT，MyISAM表在从库上仍高概率出错，因为：
- 非确定性函数（如
NOW()、UUID()、USER()）在从库执行结果可能不同，触发复制中断 - MyISAM表锁粒度是表级，大DML期间阻塞整个表，容易与其它并发操作冲突，导致
Last_SQL_Error含Table is read only或Got error 1296 - 崩溃恢复机制与InnoDB不一致，relay log中某条语句执行一半崩溃后，MyISAM无法回滚，下次START SLAVE会重复应用或跳过，引发数据不一致
为什么不能只改从库引擎
把从库MyISAM表ALTER TABLE t ENGINE=InnoDB看似简单，但实际埋雷：
- 主库仍是MyISAM，后续DDL（如
ADD COLUMN）在从库执行时，会因引擎不一致被拒绝，报Storage engine mismatch - 主从表结构元数据不一致，
mysqldump --single-transaction等工具行为异常，备份恢复链断裂 - 某些中间件或监控依赖
information_schema.tables.engine做路由或告警，引擎混用会导致误判
必须主库先转，再让从库同步——不是“推荐”，是唯一能闭环的路径。
大表转换时最常踩的坑
主库执行ALTER TABLE t ENGINE=InnoDB时，MyISAM不支持ALGORITHM=INPLACE，全程COPY模式，这带来三个硬约束：
- 该表DML完全阻塞，业务写入挂起，持续时间≈表大小 / 磁盘IO吞吐
- binlog记录的是完整建表+导入过程，从库需同步执行同样耗时操作，复制延迟可能飙升数小时
- 若表>50GB，建议先在从库停SQL线程后单独转换，验证
SELECT COUNT(*)和主库一致，再切主库操作——否则一次失败就得全量重建从库
别信“跳过错误继续同步”的临时方案，MyISAM引发的复制中断从来不是单点故障，而是状态漂移的起点。修复窗口越拖越窄，最终往往只剩重新搭从库一条路。
