ROLLBACK对MyISAM表完全无效，因其无undo log且不参与事务，混用时仅InnoDB部分可回滚，MyISAM操作立即落盘不可逆，导致数据不一致、备份错乱、主从复制中断及高可用切换失败。
ROLLBACK对MyISAM表完全无效
事务中混用InnoDB和MyISAM时，ROLLBACK只撤回InnoDB部分，MyISAM的INSERT、UPDATE已立即落盘且不可逆。这不是“部分回滚”，而是根本没进事务上下文。
常见现象：SELECT查MyISAM表能看到刚写入的数据，但InnoDB表已还原；日志表（MyISAM）有记录，订单表（InnoDB）却因异常被回滚——对账直接断裂。
根本原因：MyISAM没有undo log，也不参与两阶段提交（2PC），BEGIN对其无意义。
- 别指望应用层靠
try...catch加补偿逻辑兜底——失败路径多、时序难控、幂等难保 - MySQL 8.0+系统表全为InnoDB，继续混用等于主动绕过官方一致性保障
mysqldump备份必然不一致
mysqldump --single-transaction对MyISAM表完全失效，工具会静默退化为--lock-all-tables，整个库加全局读锁。这不是“慢一点”，而是业务写入直接卡死。
更危险的是“伪成功”：备份文件里InnoDB表是T时刻快照，MyISAM表却是T+Δt状态，恢复后查不到关联数据或出现重复日志。
- 若必须保留MyISAM表，
mysqldump需显式加--lock-tables并接受停写，且不能和--single-transaction共用（后者会被忽略） -
mydumper --less-locking仅在MyISAM表极少且版本≥0.10.0时缓解，不是解药
主从复制极易中断或静默错乱
ROW格式binlog无法安全应用到MyISAM表：主库执行UPDATE t_innodb JOIN t_myisam，从库重放时可能因字段顺序、默认值或索引结构差异直接失败，报ERROR 1032或ERROR 1594。
更麻烦的是“静默错乱”：某些语句在MyISAM上执行失败但未报错，SQL线程标记为成功，数据实际已偏移——SHOW SLAVE STATUS显示Running: Yes，直到某次对账才发现主从差了27条记录。
-
read_only=ON对MyISAM无效：INSERT DELAYED和LOAD DATA INFILE仍可写入，破坏只读语义 - 主库
ALTER TABLE，从库若为MyISAM会直接中断复制，且无法自动恢复
高可用切换后MyISAM表大概率损坏
MHA、InnoDB Cluster等高可用方案发生主库宕机切换时，MyISAM表因无崩溃恢复机制，新主库常报Table is marked as crashed或Got error 127 from storage engine。
这不是小概率事件——只要主库异常退出前有未刷盘的.MYD缓冲，或索引页写一半，从库接管后就会触发校验失败。修复必须REPAIR TABLE，而这是阻塞式操作，等于二次停服。
CHECK TABLE在MyISAM上会全表扫描索引文件，期间表不可写，线上执行等于主动卡死。
