MyISAM表不支持事务，其操作立即生效且无法回滚，导致与InnoDB混用时出现数据不一致、主从错位、高可用故障等严重风险。
事务回滚对MyISAM表完全无效
MySQL 的 BEGIN/COMMIT/ROLLBACK 仅作用于 InnoDB 表；MyISAM 表的变更在语句执行完成时即落盘，不参与事务。哪怕你显式关闭了 AUTOCOMMIT、手动 BEGIN，对 MyISAM 的 UPDATE 或 DELETE 仍会立即生效，且无法撤回。
常见错误现象：
- 事务中先改 MyISAM 表（如日志表），再改 InnoDB 表（如订单表），InnoDB 回滚后，MyISAM 日志已写入，业务状态不一致
-
INSERT ... ON DUPLICATE KEY UPDATE在 MyISAM 上实际是“删+插”，自增 ID 跳变，且该过程不可原子化 - 应用层误用
SELECT ... FOR UPDATE—— MyISAM 完全忽略该语法，不加锁，但应用以为已上锁，引发并发覆盖
主从复制中 MyISAM 表极易导致数据错位
MyISAM 没有事务上下文，binlog 中的事件顺序与实际文件写入顺序不严格绑定。尤其在 STATEMENT 格式下，NOW()、UUID() 等函数在主从生成不同值；即使使用 ROW 格式，MyISAM 表崩溃后 REPAIR TABLE 只重建索引，不校验数据逻辑一致性。
实操风险点：
- 主库异常宕机后切换到从库，MyISAM 表常报
Table is marked as crashed或Got error 127 from storage engine - 从库执行
REPLACE INTO后看似成功，但金额/状态字段已错位，且 binlog 和 error log 均无报错 - mysqldump 导入含
ENGINE=MyISAM的 SQL 时，服务端照单全收，旧备份还原到新环境极易引入隐患
高可用集群切换时 MyISAM 成为单点故障源
MHA、Orchestrator 或 InnoDB Cluster 等工具默认假设所有表具备崩溃可恢复能力。而 MyISAM 表在主库宕机后，从库提升为主库时大概率处于“索引与数据不同步”状态，表现为查询结果矛盾（如 COUNT(*) 与 SELECT * 行数不一致）或直接拒绝写入。
关键细节：
- SHOW TABLE STATUS 中
Comment字段显示Crashed，但 MySQL 不主动告警，需 DBA 主动巡检 - 某些系统表（如
mysql.columns_priv）在老版本中可能是 MyISAM，集群切换失败常源于此 - 即便配置了
disabled_storage_engines="MyISAM"，已有 MyISAM 表仍可读写，不会自动转换，隐患长期存在
混合引擎让优化器行为变得不可预测
InnoDB 和 MyISAM 的索引结构、锁机制、统计信息收集方式完全不同。当 JOIN 涉及两种引擎表时，优化器可能选错驱动表，或因 MyISAM 缺乏行级统计导致 EXPLAIN 显示的 rows 严重失真。
典型陷阱：
- OR 条件在 InnoDB 下基本不走索引，但若其中一张表是 MyISAM，优化器可能启用
index_merge，造成执行计划在主从间不一致 - MyISAM 全文索引支持布尔模式
*截断，InnoDB 不支持；混用时MATCH AGAINST结果在不同表上表现不一 - 临时表默认引擎由
default-storage-engine决定，若设为 MyISAM，存储过程中创建的临时表将脱离事务控制，ROLLBACK后数据仍在
myisamchk 强制修复，且修复后无法验证业务逻辑是否仍自洽。 
