MySQL 中 InnoDB 和 MyISAM 有什么区别？

简化版

InnoDB 支持事务、行级锁、外键、崩溃恢复和 MVCC，是 MySQL 默认且主流的存储引擎；MyISAM 不支持事务，主要使用表级锁，适合早期读多写少场景，现在业务表通常优先选 InnoDB。

详细版

InnoDB 和 MyISAM 的核心区别在于能力边界。InnoDB 面向事务型业务，支持 ACID、行锁、崩溃恢复、MVCC 和聚簇索引；MyISAM 更轻量，但没有事务和崩溃恢复能力，写入时表级锁冲突更明显。

面试时不要只背“一个行锁一个表锁”。更完整的回答应覆盖：事务、锁粒度、索引结构、崩溃恢复、外键、并发能力和适用场景。现代线上业务涉及订单、支付、库存、账户等一致性要求时，InnoDB 基本是默认选择。

MyISAM 并非完全没有价值，某些历史系统、只读归档表或特殊全文检索场景可能还能看到它，但新系统一般不建议作为核心业务表引擎。

完整版教学

一、存储引擎到底负责什么

MySQL 的 Server 层负责连接、解析、优化和执行调度，真正的数据组织、索引维护、锁、事务和崩溃恢复由存储引擎负责。

可以把结构理解为：

客户端 SQL
  -> MySQL Server 层：解析、优化、执行器
  -> 存储引擎层：InnoDB / MyISAM
  -> 磁盘文件与内存缓存

所以同样一条 INSERT 或 SELECT，不同存储引擎在锁、日志、索引和恢复上的行为可能完全不同。

记忆钩子：Server 层决定“怎么问”，存储引擎决定“数据怎么存、怎么锁、怎么恢复”。

二、事务能力是第一分水岭

InnoDB 支持事务，能通过 COMMIT 和 ROLLBACK 控制一组操作的原子性。

START TRANSACTION;
UPDATE account SET balance = balance - 100 WHERE id = 1;
UPDATE account SET balance = balance + 100 WHERE id = 2;
COMMIT;

如果第二条更新失败，InnoDB 可以回滚第一条，避免钱扣了但没到账。MyISAM 不支持事务，一旦写入完成，就没有同等级别的事务回滚能力。

能力	InnoDB	MyISAM
事务	支持	不支持
回滚	支持	不支持事务回滚
崩溃恢复	依赖 redo log 等机制	较弱
业务一致性	适合核心业务	不适合强一致写入

这也是为什么交易类业务必须优先考虑 InnoDB。

三、锁粒度决定并发写入能力

InnoDB 支持行级锁，查询命中索引时可以只锁相关记录或范围；MyISAM 主要是表级锁，写入时容易阻塞整张表。

假设有 1000 万行订单，两个事务更新不同订单：

UPDATE orders SET status = 'paid' WHERE id = 100;
UPDATE orders SET status = 'cancelled' WHERE id = 200;

在 InnoDB 中，如果 id 是索引，两次更新可以锁不同记录，并发性较好。表级锁模型下，一次写入可能让另一写入等待整张表释放。

不过要注意：InnoDB 行锁建立在索引访问基础上。如果条件没有走索引，可能扫描并锁住更多记录，面试里补充这一点会显得更扎实。

四、索引结构和数据文件不同

InnoDB 使用聚簇索引组织数据，主键索引的叶子节点保存整行数据；二级索引叶子节点保存主键值，再通过主键回表。

MyISAM 的索引和数据分离，索引叶子节点通常保存数据文件位置。

InnoDB 主键索引叶子：主键 -> 整行数据
InnoDB 二级索引叶子：二级键 -> 主键值
MyISAM 索引叶子：索引键 -> 数据文件地址

这带来一个重要后果：InnoDB 表最好有稳定、短小、递增的主键，因为主键会出现在每个二级索引叶子节点中。若主键是 64 字节字符串，5 个二级索引都会额外承担更大的存储成本。

五、崩溃恢复和日志机制差异

InnoDB 通过 redo log、undo log、doublewrite buffer 等机制提高崩溃恢复能力。服务器宕机后，可以根据日志恢复已提交事务，回滚未提交事务。

简单流程：

事务修改页
-> 先写 redo log
-> 脏页稍后刷盘
-> 崩溃后用 redo 重放已提交修改

MyISAM 缺少完整事务日志体系，异常宕机后更容易出现表损坏或数据不一致，需要修复工具处理。

对面试来说，不需要把所有恢复细节展开到源码级，但必须讲出：InnoDB 是事务型存储引擎，日志和恢复能力是它成为默认选择的重要原因。

六、怎么选择存储引擎

现代业务表几乎默认 InnoDB，原因是大多数系统都需要并发写入、事务、一致性和崩溃恢复。

MyISAM 的使用场景越来越少，可能出现在历史系统、只读归档、极少更新的报表表中。但只要涉及订单、账户、库存、用户核心数据，就不应把 MyISAM 作为默认选项。

选择可以按这个表判断：

场景	推荐	理由
订单支付	InnoDB	事务和恢复必需
高频读写业务表	InnoDB	行锁和 MVCC 更适合
历史只读归档	InnoDB 或特殊评估	仍建议统一引擎
老系统 MyISAM 表	谨慎迁移	需要评估锁和事务语义变化

七、常见误区与追问

误区：InnoDB 和 MyISAM 只是锁粒度不同。 事务、恢复、索引组织、外键和并发模型都不同。
误区：MyISAM 读一定比 InnoDB 快。 真实性能取决于版本、索引、缓存、查询模式和并发压力。
误区：InnoDB 使用行锁就永远只锁一行。 未命中索引或范围查询可能锁住更多记录和间隙。
误区：业务表可以随便选存储引擎。 核心业务通常需要事务和崩溃恢复，默认应选 InnoDB。
追问：为什么 InnoDB 主键很重要？ InnoDB 是聚簇索引组织表，主键决定数据组织方式，也会被二级索引引用。
追问：MyISAM 还会在哪里出现？ 主要是历史系统、特殊只读表或老版本遗留场景，新业务较少主动选择。

八、加强记忆

这道题按“事务、锁、索引、恢复、场景”五个词回答最稳。InnoDB 是面向事务和并发业务的主流引擎，MyISAM 是早期轻量引擎；真正拉开差距的不是某一个特性，而是 InnoDB 在一致性、恢复和并发上的整体能力。

简化版

详细版