type
Post
status
Published
date
Dec 18, 2025
slug
mysql5
summary
tags
技术探索
category
icon
password
MySQL 默认存储引擎是 InnoDB。
那问题来了：为什么 MySQL 要选择 InnoDB 作为默认存储引擎？
很多人一对比InnoDB和MyISAM,就脱口而出:是不是因为 InnoDB 支持事务？
答案是：事务确实是最关键的原因，但不是唯一原因。
数据库默认引擎不是随便选的。
因为默认引擎意味着：大多数业务在建表时，如果不特别指定存储引擎，就会使用它。
所以它必须足够通用、足够可靠，并且能适应大多数业务场景。
早期 MySQL 中，MyISAM 也很常见。它结构简单，适合一些读多写少、事务要求不高的场景。
但现代业务系统不只是“把数据存进去”这么简单，还要求：
数据不能乱。并发不能崩。宕机后能恢复。业务操作要么全部成功，要么全部失败。
这些能力，正是 InnoDB 比 MyISAM 更适合作为默认引擎的原因。
一、InnoDB 支持事务，更适合复杂业务场景
InnoDB 最核心的优势，就是支持事务。
事务的价值，是保证一组操作要么全部成功，要么全部失败。
比如订单创建，往往不只是插入一条订单记录，还可能涉及：
写入订单表写入订单明细表扣减商品库存更新优惠券状态生成支付流水
这些操作必须作为一个整体来看。
如果订单生成了，但库存没有扣减；或者库存扣减了，但订单没有创建成功，业务数据就会出现混乱。
这时候，事务就非常重要。
MyISAM 不支持事务，如果要保证这类业务一致性，就必须在应用层做很多额外控制，复杂度会明显上升。
所以，InnoDB 成为默认存储引擎的关键，不只是因为它“支持事务”，而是因为它能让数据库更可靠地维护业务状态。
二、InnoDB 通过 redo log 和 undo log 保证可靠性
数据库要真正做到“提交了不能丢，失败了能回滚”，背后必须有日志机制。
InnoDB 里比较关键的是 redo log 和 undo log。
redo log：重做日志，主要保证事务的持久性和崩溃恢复。undo log：回滚日志，主要支持事务回滚，同时也是 MVCC 的基础。
比如一个事务已经提交，但数据页还没来得及刷盘，数据库突然宕机了。
这时候，InnoDB 可以通过 redo log 恢复已经提交的修改，保证提交后的数据不会丢。
再比如一个事务执行到一半失败了，需要回滚。
这时候，InnoDB 可以通过 undo log 撤销之前的修改，让数据回到事务执行前的状态。
从 ACID 角度看：
原子性：主要依赖 undo log 支持回滚。持久性：主要依赖 redo log 支持崩溃恢复。隔离性：依赖锁机制和 MVCC。一致性：由事务机制、约束和业务逻辑共同保证。
相比之下，MyISAM 的崩溃恢复能力较弱，这也是它不适合作为现代默认引擎的重要原因。
三、InnoDB 支持行级锁，高并发写入能力更好
除了事务和日志，锁机制也是 InnoDB 的重要优势。
MyISAM 主要使用表级锁。
也就是说，当一个线程修改一张表中的数据时，可能会影响整张表的并发操作。
而 InnoDB 支持行级锁，尽量只锁住当前操作涉及到的行。
比如：
如果
id 是主键或索引字段，InnoDB 可以比较精准地定位到这条记录，并锁住对应的行。这样其他事务如果操作的是不同订单，就可以更好地并发执行。
这对互联网业务很重要。
因为线上系统不是一个用户在访问数据库，而是大量请求同时读写数据。如果锁粒度太粗，并发性能就会明显下降。
不过这里要注意一点：
InnoDB 的行级锁优势依赖索引设计。
如果 SQL 没有走索引，或者扫描范围很大，就可能锁住更多记录，导致锁冲突变严重。
所以更准确地说，InnoDB 具备更好的并发能力，但前提是 SQL 和索引设计要合理。
四、InnoDB 支持 MVCC，读写并发能力更强
InnoDB 的并发能力不只来自行级锁，还来自 MVCC。
MVCC，全称是多版本并发控制。
简单理解就是：InnoDB 会通过 undo log 保存数据的历史版本，再配合 Read View，让普通查询可以读取某个一致性版本的数据。
这样做的好处是：
普通读操作不一定阻塞写操作。写操作也不一定阻塞普通一致性读。
比如一个事务正在修改某条订单数据，另一个事务此时执行普通
SELECT 查询，不一定非要等待写锁释放，而是可以读取旧版本数据。这让 InnoDB 在高并发读写场景下，比单纯依赖锁的方式更高效。
不过要注意，这里说的是普通
SELECT 这类一致性读。如果是：
这类当前读或写操作，仍然会涉及加锁。
所以，MVCC 是让普通一致性读在很多场景下不需要被写操作阻塞。
这也是 InnoDB 更适合作为默认引擎的重要原因：它既要保证一致性，也要尽量提高并发性能。
五、InnoDB 使用聚簇索引，主键访问效率更高
InnoDB 还有一个重要特点：使用聚簇索引组织数据。
简单来说：
主键索引的叶子节点里存放的就是整行数据。
所以，如果按照主键查询：
InnoDB 可以通过主键索引直接定位到整行数据。
这也是为什么 InnoDB 表通常建议设计一个合适的主键。
不过，聚簇索引不是 MySQL 默认选择 InnoDB 的决定性原因。
它更多说明的是：InnoDB 不只是解决事务问题，在数据组织和主键访问效率上，也有自己的设计优势。
六、InnoDB 还支持外键，但不是核心原因
外键可以在数据库层面保证表与表之间的参照完整性。
比如订单表中的
user_id，应该对应用户表中真实存在的用户：这样可以避免订单表里出现一个不存在的用户 ID。
不过在很多互联网项目中，外键不一定会大量使用。
因为外键可能会增加表之间的耦合，影响写入性能，也不太适合分库分表等场景。
所以，外键可以作为 InnoDB 的一个完整性能力来看，但它不是 MySQL 默认选择 InnoDB 的核心原因。
七、为什么不是 MyISAM？
理解 InnoDB 为什么成为默认引擎，最好和 MyISAM 对比来看。
MyISAM 的主要问题是：
不支持事务，复杂业务一致性难保证。主要使用表级锁，高并发写入能力较弱。崩溃恢复能力较弱，异常宕机后数据可靠性不如 InnoDB。更适合早期读多写少、业务逻辑简单的场景。
而 InnoDB 的优势是：
支持事务和 ACID，适合订单、支付、转账等强一致性场景。通过 redo log 和 undo log 支持崩溃恢复和事务回滚。支持行级锁和 MVCC，高并发读写能力更好。使用聚簇索引组织数据，主键访问效率较高。支持外键，具备数据库层面的完整性约束能力。
所以，MySQL 默认选择 InnoDB，本质上不是因为 MyISAM 不能用，而是因为 InnoDB 更适合现代业务系统。
总结
MySQL 默认选择 InnoDB，是因为它在几个关键维度上更适合作为通用默认引擎。
事务保证业务操作的原子性和一致性。
redo log 和 undo log 提供崩溃恢复与回滚能力。
行级锁和 MVCC 提升高并发读写能力。
聚簇索引和外键则进一步补充了数据组织和完整性约束能力。
相比之下，MyISAM 不支持事务，主要依赖表级锁，崩溃恢复能力也较弱，更适合早期读多写少、业务简单的场景。
因此，InnoDB 成为默认引擎，本质上是因为它更适合事务型、高并发、可靠性要求更高的现代业务系统。
InnoDB 不是只比 MyISAM 多了事务，而是在一致性、可靠性、并发能力和通用业务适配性上，更适合作为 MySQL 的默认存储引擎。
分享