InnoDB取代MyISAM是因后者表级锁、无事务、崩溃恢复弱等缺陷无法满足现代业务需求，而InnoDB持续强化事务、行锁、MVCC、崩溃恢复及复制可靠性，成为MySQL 5.6+唯一演进主线。
InnoDB 在 MySQL 5.6 及以后版本中取代 MyISAM，不是因为“性能突然变强”，而是因为 MyISAM 的核心缺陷在现代业务场景下已无法容忍，而 InnoDB 的关键能力（事务、行锁、崩溃恢复）被持续加固，最终形成事实标准。
MyISAM 表级锁在高并发写入时直接卡死
MyISAM 对所有 UPDATE、DELETE、INSERT 操作都加整表锁，哪怕只改一行，其他写请求全部排队。实际业务中常见现象是：show processlist 里一堆 Waiting for table metadata lock 或 Locked 状态。
- 并发写入量 > 10 QPS 时，响应延迟就明显抖动
- DDL（如
ALTER TABLE）期间整个表不可写，运维窗口极难安排 - 没有 MVCC，
SELECT也会被写操作阻塞（读也得等锁）
InnoDB 的事务与崩溃恢复机制成为生产底线
MyISAM 崩溃后只能靠 myisamchk 修复，且无法保证数据一致性；InnoDB 则依赖 redo log 和 undo log 实现 ACID，MySQL 异常退出重启后自动回滚未提交事务、重放已提交但未落盘的操作。
- 配置项
innodb_flush_log_at_trx_commit=1（默认）可确保每次COMMIT都刷盘，断电不丢事务 -
mysqld启动时自动执行 crash recovery，无需人工干预 - MyISAM 的
.MYD/.MYI文件损坏即可能丢失部分数据，InnoDB 的.ibd文件即使损坏，也能从日志中还原到最近一致点
MySQL 官方停止为 MyISAM 加新特性，InnoDB 成唯一演进主线
从 MySQL 5.6 开始，所有关键优化都只针对 InnoDB：全文索引支持（5.6.4）、虚拟列（5.7）、JSON 类型（5.7）、并行查询（8.0）、原子 DDL（8.0）——MyISAM 连这些基础能力都没有。
-
SHOW ENGINES中 MyISAM 的SUPPORT字段在 8.0+ 已变为NO（仅保留兼容性） - 系统表（如
mysql.user、information_schema）在 8.0 全部强制使用 InnoDB - 复制协议（GTID、并行复制）和备份工具（
mysqldump --single-transaction）都深度绑定 InnoDB 的 MVCC 特性
独立表空间让 InnoDB 的运维更可控
MySQL 5.6 默认开启 innodb_file_per_table=ON，每个表对应一个 .ibd 文件，删表后磁盘空间可立即回收；而 MyISAM 的 .MYD/.MYI 文件删除后，共享表空间（ibdata1）仍残留碎片，长期运行易膨胀。
-
OPTIMIZE TABLE对 MyISAM 是“重建表+整理碎片”，对 InnoDB 是“重建聚簇索引+释放空页”，效果更稳定 - 单表迁移、冷备恢复、Percona XtraBackup 增量备份都依赖
.ibd文件粒度 - 误删
.ibd文件后，只要ibdata1和ib_logfile完好，还能用innodb_force_recovery尝试抢救
binlog 记录的是语句级（STATEMENT），而非行变更，一旦主库执行了 INSERT ... SELECT 或含函数的非确定性 SQL，从库极易出现数据不一致——而 InnoDB + ROW 格式 binlog 是现在唯一被广泛验证可靠的复制方案。 
