MyISAM不支持事务，导致跨引擎操作存在回滚失效、JOIN性能差、备份不一致、外键和分区表限制等问题，需应用层补偿且问题常延迟暴露。
事务回滚时MyISAM部分无法撤销
在一个 BEGIN...COMMIT 事务里同时更新 InnoDB 表和 MyISAM 表，ROLLBACK 只能撤回 InnoDB 的变更，MyISAM 的写入已立即生效且不可逆。这会导致数据逻辑断裂——比如订单表（InnoDB）和日志表（MyISAM）一起更新，回滚后订单没了但日志还在。
- 现象：事务失败后查
MyISAM表发现数据已变，但InnoDB表还原了 - 根本原因：MyISAM 不支持事务，没有 undo log 机制
- 修复成本高：必须靠应用层补偿逻辑，比如手动删日志、发消息重试
跨引擎 JOIN 查询性能断崖式下跌
EXPLAIN 显示 type 字段为 ALL 或 index，说明被驱动的 MyISAM 表没走索引——不是 SQL 写得差，而是 MySQL 优化器压根没法把 InnoDB 的 B+ 树索引下推到 MyISAM 的 BTREE 结构上。
- 强制用
STRAIGHT_JOIN把InnoDB表放前面，避免优化器误选MyISAM当驱动表 -
USE INDEX提示对跨引擎 JOIN 基本无效，别白费劲 - 真要 JOIN，先用
CREATE TEMPORARY TABLE ... SELECT把MyISAM表导入临时InnoDB表再操作
备份时一致性无法保障
mysqldump 的 --single-transaction 只对 InnoDB 有效，遇到 MyISAM 表会自动退化成 --lock-all-tables，整个库加全局读锁，业务写入全卡住。
- 混合场景下，想“不停服备份”基本不可能
- 若只导出单个
MyISAM表，--lock-tables锁的是该表，但同一事务里的InnoDB表可能已提交，快照不一致 - Percona XtraBackup 对
MyISAM是全库加锁，比mysqldump更重
外键和分区表直接报错
MySQL 明确禁止跨引擎外键：ALTER TABLE t1 ADD FOREIGN KEY (ref_id) REFERENCES t2(id) 会失败，只要 t1 和 t2 引擎不同；分区表更狠——哪怕只一个分区用 MyISAM，整个表就失去事务原子性。
- 分区表混用引擎（如
PARTITION p0 ENGINE=MyISAM）会导致批量导入失败时不回滚，产生“幽灵数据” - 外键约束在
MyISAM上是语法允许但实际不生效，容易误以为有保护 - MySQL 8.0 已默认禁用
MyISAM自动创建，升级时老建表语句直接报Storage engine MyISAM is disabled
真正难处理的不是技术能不能做，而是问题暴露有延迟：上线初期流量低看不出锁争用，备份脚本跑通了但某次大促时才发现数据不一致。一旦混合使用，就得全程为两种引擎的差异兜底，而不是只改一行 ENGINE=InnoDB 那么简单。
