innodb 是现代 mysql 应用的首选引擎，因其支持 acid 事务、行级锁、聚集索引及崩溃恢复能力，适用于订单、支付等强一致性高并发场景；myisam 仅适合纯读静态库等极少数例外。
MyISAM 和 InnoDB 是 MySQL 最核心的两种存储引擎，选错会影响数据安全、并发能力甚至业务逻辑。它们不是简单“快慢”之分，而是设计哲学和适用场景的根本差异。
事务与数据一致性
InnoDB 支持完整的 ACID 事务，具备 commit、rollback 和崩溃自动恢复能力。比如转账操作中，扣款和入账必须同时成功或同时失败，否则会引发资金异常——这类逻辑只能靠 InnoDB 保障。MyISAM 完全不支持事务，任何写操作中途出错，已执行的部分无法回退，数据可能处于中间不一致状态。
- InnoDB 的事务日志（redo log）确保写入持久化，即使断电也能恢复
- MyISAM 没有事务日志，崩溃后常需运行 myisamchk 手动修复，且可能丢失数据
- 如果业务涉及订单、支付、库存扣减等强一致性场景，InnoDB 是唯一合理选择
锁机制与并发能力
MyISAM 只支持表级锁：一个 UPDATE 正在执行，整张表就不可写，其他写请求全部排队；读操作虽可并发，但遇到写锁时也会被阻塞。InnoDB 默认行级锁，只锁定 WHERE 条件匹配的那些行，其余行照常读写。
- 例如执行 UPDATE users SET status=1 WHERE id=1005，MyISAM 锁全表，InnoDB 仅锁 id=1005 这一行
- 当 SQL 无法使用索引（如 WHERE name LIKE ‘%abc’），InnoDB 也可能升级为锁表，所以索引设计很关键
- 高并发更新场景下，MyISAM 容易出现大量锁等待，TPS 明显下降
索引结构与查询特性
两者都用 B+ 树，但组织方式不同：MyISAM 是非聚集索引，索引叶节点存的是数据行的物理地址；InnoDB 是聚集索引，主键索引的叶节点直接存整行数据，普通索引叶节点存的是主键值。
- 这意味着 InnoDB 的主键查询极快（一次定位即得数据），但主键不宜过长——因为所有二级索引都冗余存储主键值
- MyISAM 的 COUNT(*) 非常快，因为它在表元数据中缓存了精确行数；InnoDB 每次都要遍历索引统计，速度随数据量增长而下降
- MyISAM 原生支持全文索引（5.6 以前），InnoDB 在 5.6.4+ 才加入，且对中文分词支持仍弱于 MyISAM
适用场景与实际建议
MySQL 自 5.5 起已将 InnoDB 设为默认引擎，这不是偶然。绝大多数现代应用应优先选 InnoDB，除非明确满足以下条件：
- 纯静态内容展示类系统（如老式 CMS、文档库），几乎无写入，且需要高频 COUNT(*) 或全文检索
- 嵌入式或资源受限环境，对内存占用极度敏感（InnoDB 缓冲池开销更大）
- 历史遗留系统迁移成本过高，且已通过应用层规避了事务与并发问题
即便如此，也建议逐步将关键表迁移到 InnoDB，尤其当业务开始引入用户交互、状态变更或数据关联时。
