InnoDB 与 MyISAM 有何区别？

核心回答

以 MySQL 8.4 为例，InnoDB 是默认的通用存储引擎。它与 MyISAM 最重要的差别是：InnoDB 支持事务、MVCC 和行级锁，并提供事务崩溃恢复；MyISAM 不支持事务和 MVCC，主要采用表级锁。 普通业务系统通常优先选择 InnoDB。

具体可以从五个方面比较：

• 事务与恢复：InnoDB 支持提交和回滚，通过日志与恢复机制处理已提交和未提交的修改。MyISAM 表的修改不能靠事务回滚；它有检查、修复工具，但这不同于事务崩溃恢复保证。
• 并发控制：InnoDB 用索引记录锁、必要的间隙锁等协调写入，并通过 MVCC 支持普通一致性读。MyISAM 的表级锁粒度较粗，并发更新容易争用。InnoDB 也可能因热点行、访问范围或长事务发生严重锁等待。
• 数据与索引组织：InnoDB 的聚簇索引叶子保存行数据，二级索引记录包含索引列与主键值，必要时根据主键回表。MyISAM 的数据和索引分开，索引项通过记录位置找到数据，主键也不承担 InnoDB 那样的聚簇组织作用。
• 外键：InnoDB 支持外键约束，MyISAM 不支持。是否在项目中使用外键，是另一层设计取舍。
• 缓存：InnoDB 的 Buffer Pool 缓存数据页和索引页；MyISAM 的 Key Cache 主要缓存索引块，数据块依赖操作系统文件缓存，不能说它“完全没有数据缓存”。

选型时，我会先看是否需要多步操作一起提交、并发更新和故障恢复，再看具体查询、数据量及维护成本，不直接套用“MyISAM 查询一定更快”。

进一步解释

为什么订单、库存这类表通常选择 InnoDB？

以参考业务为例，“扣减库存、写入订单”需要作为一个整体提交。如果后一步失败，前一步应能回滚；多人同时下单时，还需要条件更新或锁来协调库存争用。这些需求与 InnoDB 的事务及并发控制能力直接相关。

如果其中一张表使用 MyISAM，即使外层开启了事务，也不能把对这张表已经发生的修改一并回滚。因此，“使用了事务语句”不等于所有参与的表都获得事务保证。

行级锁是不是每次只锁一行？

不是。InnoDB 的锁与访问的索引记录、查询范围和隔离级别有关。查询条件不合适，可能扫描并锁住大量记录；范围访问还可能涉及间隙。不能把“支持行级锁”理解成任何 SQL 都只影响一行，也不应机械解释成“没有索引就自动升级成表锁”。

MyISAM 也不是任何情况下读写都绝对不能并行，它在满足条件时支持并发插入；但这种能力不能替代事务和细粒度并发控制。

版本与选型还要注意什么？

MyISAM 并未在 MySQL 8.4 中消失。已有系统或经过验证的特殊用途，仍可能使用它的特性，但应明确非事务、锁竞争和修复成本。只因为“读多写少”就切换引擎，依据并不充分。

也不要沿用“InnoDB 不支持全文索引”的旧结论；8.4 中两者都支持全文索引。文件布局同样要看版本：8.4 的 MyISAM 数据、索引文件分别为 .MYD、.MYI，表定义由 MySQL 数据字典管理，不能再套旧版 .frm 的说法。

常见追问

InnoDB 表必须手工声明主键吗？

强烈建议明确设计合适的主键，但不是不写就不能建表。没有显式主键时，InnoDB 会选择合适的非空唯一索引作为聚簇索引；再没有，就生成隐藏的行 ID 和聚簇索引。

事务支持是不是意味着宕机后绝不会丢数据？

仍要看持久化配置和存储是否正确兑现刷盘。事务崩溃恢复、复制、备份分别解决不同问题，不能仅凭使用 InnoDB 就忽略这些条件。

参考资料