在 MySQL 的面试中，存储引擎的选择几乎是必问的题目。而 InnoDB 与 MyISAM 作为最常被拿来对比的两个引擎，它们之间的差异不仅体现在“支不支持事务”这一句话上，更涉及锁机制、索引结构、并发性能、崩溃恢复等多个层面。如果你只是回答“InnoDB 支持事务，MyISAM 不支持”，大概率只能拿到及格分。这篇文章将带你系统梳理两者的核心区别，并解释这些区别背后的设计原理。
一、事务支持：最根本的分水岭
InnoDB 是事务型存储引擎，支持 ACID 特性，包括原子性、一致性、隔离性和持久性。你可以通过 BEGIN、COMMIT、ROLLBACK 来控制事务边界，也可以设置不同的隔离级别（读未提交、读已提交、可重复读、串行化）来平衡一致性与并发性能。
MyISAM 不支持事务。每条 SQL 语句都是自动提交的，一旦执行就立即生效，无法回滚。这意味着如果在一个多步操作中间发生错误，前面已经执行的语句无法撤销，数据可能处于不一致状态。
面试延伸：InnoDB 的可重复读隔离级别通过 MVCC（多版本并发控制）和 Next-Key Lock 在很大程度上避免了幻读，而 MyISAM 由于没有事务，根本不存在隔离级别的概念。
二、锁机制：行锁与表锁的鸿沟
InnoDB 支持行级锁（Row-Level Locking），默认情况下，写操作只锁定被修改的行（当然，在可重复读级别下，范围查询可能会锁住间隙）。行锁大大降低了并发写入时的锁冲突概率，使得多个事务可以同时修改不同行的数据。
MyISAM 只支持表级锁（Table-Level Locking）。任何写操作都会锁定整张表，其他读写操作必须等待锁释放。对于读多写少的场景（如博客、新闻网站），表锁的代价尚可接受；但在写并发较高的场景下，MyISAM 的性能会急剧下降。
此外，InnoDB 还支持意向锁（IS、IX），用于在行锁与表锁共存时快速判断兼容性；MyISAM 则只有共享读锁和独占写锁两种表锁模式。
三、索引结构：聚簇索引与非聚簇索引
这是很多面试官喜欢深挖的点。
InnoDB 使用聚簇索引（Clustered Index）组织数据。主键索引的叶子节点直接存储完整的行数据，也就是说，数据文件本身就是按主键顺序排列的索引文件。二级索引的叶子节点存储的是主键值，查询二级索引后通常需要“回表”到主键索引中获取完整行记录。
MyISAM 使用非聚簇索引（Non-Clustered Index）。索引文件和数据文件是分离的，索引的叶子节点存储的是行数据的物理地址（文件偏移量）。因此，MyISAM 的索引查询都需要一次额外的磁盘寻址来读取数据行。
关键差异：
- InnoDB 的主键查询效率极高，因为一次索引查找就能拿到整行数据。
- MyISAM 的索引和数据分离，主键查询也需要回表（通过地址访问数据文件）。
- InnoDB 建议使用自增主键，避免页分裂；MyISAM 对此不敏感。
四、外键支持
InnoDB 支持外键约束（Foreign Key），可以在数据库层面保证引用完整性。例如，订单表中的用户 ID 必须存在于用户表中，删除用户时可以选择级联删除或置空。
MyISAM 不支持外键。如果业务需要外键约束，只能在应用层手动实现，这增加了代码复杂性和出错风险。
五、崩溃恢复与数据安全
InnoDB 拥有 redo log（重做日志）和 undo log（回滚日志），配合 doublewrite buffer 等机制，能够在数据库崩溃后自动进行崩溃恢复，保证已提交事务的持久性和未提交事务的回滚。
MyISAM 没有类似的日志机制。如果数据库异常宕机，MyISAM 表很容易出现数据损坏，需要使用 myisamchk 工具修复，且修复过程可能丢失数据。对于金融、订单等对数据安全要求高的场景，MyISAM 基本不可用。
六、并发性能与适用场景
| 维度 | InnoDB | MyISAM |
|---|---|---|
| 事务 | 支持 | 不支持 |
| 锁粒度 | 行锁 | 表锁 |
| 索引结构 | 聚簇索引 | 非聚簇索引 |
| 外键 | 支持 | 不支持 |
| 崩溃恢复 | 完善 | 较弱 |
| 全文索引 | 5.6+ 支持 | 支持（较早） |
| 计数查询 | 需扫描索引 | 保存行数，COUNT(*) 极快 |
| 适用场景 | OLTP、高并发写、事务性业务 | 读多写少、日志、静态数据 |
MyISAM 的一个优势是 COUNT(*) 查询非常快，因为它内部维护了一个行数计数器。而 InnoDB 需要实时扫描索引来计算行数（除非使用近似值）。不过从 MySQL 8.0 开始，InnoDB 的 COUNT(*) 也做了优化，差距在缩小。
七、面试常见追问
-
为什么 InnoDB 推荐自增主键？
因为聚簇索引按主键顺序存储数据，自增主键保证新数据顺序插入，避免随机插入导致的页分裂和碎片。 -
MyISAM 的索引一定比 InnoDB 快吗？
不一定。简单查询下 MyISAM 可能略快，因为不需要维护事务和 MVCC。但在高并发或复杂查询下，InnoDB 的行锁和缓存机制往往表现更好。 -
可以将 MyISAM 表转换为 InnoDB 吗？
可以，使用ALTER TABLE table_name ENGINE=InnoDB;。但需要注意外键、事务和锁行为的改变。 -
MySQL 8.0 默认存储引擎是什么？
InnoDB。从 MySQL 5.5 开始，InnoDB 就已成为默认存储引擎，MyISAM 逐渐退出主流舞台。
总结
InnoDB 与 MyISAM 的核心区别可以归纳为：事务、锁粒度、索引结构、外键、崩溃恢复五个维度。InnoDB 面向现代 OLTP 场景，强调数据一致性、并发写入和安全性；MyISAM 则适合读多写少、对事务无要求的简单场景。在面试中，如果能从聚簇索引、MVCC、redo log 等底层机制展开解释，会比单纯罗列区别更有说服力。实际工作中，除非有特殊需求，否则默认选择 InnoDB 是更稳妥的决策。
未经允许不得转载：任鹏个人博客 » MySQL InnoDB 与 MyISAM 存储引擎的核心区别
