07.存储引擎架构对比
文章目录
问题: InnoDB与MyISAM在数据缓存策略（Buffer Pool vs Key Cache）、事务日志实现、崩溃恢复机制和锁粒度（行级 vs 表级）上有哪些核心差异？各自适用于哪类业务场景？
👇 点击展开/折叠 面试背诵模板（建议先背这个）
一、缓存策略：Buffer Pool vs Key Cache
InnoDB —— Buffer Pool（缓冲池）：
- 缓存数据页 + 索引页（统一缓存），是InnoDB内存架构的核心。
- 通过LRU变体（midpoint insertion）管理热数据，避免全表扫描污染缓存。
- 可配置大小（
innodb_buffer_pool_size），建议设置为物理内存的70%~80%（专用数据库服务器）。 - 脏页（已修改未落盘）由后台线程异步刷新（
innodb_flush_log_at_trx_commit控制刷盘策略）。
MyISAM —— Key Cache（键缓存）：
- 仅缓存索引页，数据页由操作系统文件缓存（Page Cache）管理。
- 索引缓存大小通过
key_buffer_size配置（默认较小，需调整）。 - 数据读取依赖于OS缓存，无法做到数据页的内存级加速。
- 无脏页管理机制，数据修改直接写入磁盘。
二、事务日志与崩溃恢复
InnoDB —— 完整的事务日志体系：
- Redo Log（重做日志）：WAL（Write-Ahead Logging）机制，事务提交前先写Redo Log（顺序写），保证持久性。崩溃恢复时通过Redo Log重放已提交事务。
- Undo Log（回滚日志）：记录事务修改前的数据版本，用于回滚和MVCC（多版本并发控制）快照读。
- Double Write Buffer（双写缓冲）：解决页半写问题（操作系统写入16KB页时崩溃），确保数据页完整性。
- 自动崩溃恢复：重启时自动检查Redo Log和Undo Log，恢复未完成事务，对用户透明。
MyISAM —— 无事务日志：
- 无Redo Log和Undo Log，不支持事务和崩溃恢复。
- 宕机或异常断电后，表可能损坏（标记为“ crashed”），需手动执行
REPAIR TABLE或myisamchk修复，且可能丢失数据。 - 依赖操作系统fsync强制刷盘，无WAL机制，写入性能存在风险（丢失已提交数据）。
三、锁粒度：行级锁 vs 表级锁
InnoDB —— 行级锁（Record Lock / Gap Lock / Next-Key Lock）：
- 锁粒度最小为索引记录（行），只锁定符合条件的行，高并发下写操作互不影响。
- 支持多种锁类型：共享锁（S）、排他锁（X）、意向锁（IS/IX）。
- 锁是在索引上实现的，若
UPDATE或DELETE未走索引，则升级为表锁（全表扫描加锁），需注意索引设计。
MyISAM —— 表级锁（Table Lock）：
- 读操作加共享锁（读锁共享，不阻塞其他读），写操作加排他锁（写锁独占，阻塞所有读写）。
- 写操作优先级高于读操作（默认写优先），可能导致读请求长时间等待（尤其写密集场景）。
四、适用场景与选型建议
| 场景特征 | 推荐引擎 | 理由 |
|---|---|---|
| 高并发OLTP（订单、支付、用户中心） | InnoDB | 行级锁 + 事务支持 + 崩溃恢复，保证数据一致性和并发性能 |
| 读多写少（报表、BI查询、数据仓库） | 可选InnoDB或MyISAM | 若数据只读且无事务需求，MyISAM体积小、读性能略优；但当前生产环境已普遍改用InnoDB，简化技术栈 |
| 全文搜索（非ElasticSearch场景） | MyISAM（旧版） / InnoDB（MySQL 5.6+） | MySQL 5.6后InnoDB支持全文索引，MyISAM优势已不明显 |
| 日志表、流水表（写入密集型） | InnoDB | 行级锁保障并发写入性能，且支持崩溃恢复，避免数据丢失 |
临时表（CREATE TEMPORARY TABLE） |
MyISAM（默认）或InnoDB | 临时表可在Memory引擎，但InnoDB也支持，需视需求而定 |
五、总结与趋势
当前MySQL 8.0中，InnoDB已成为默认且推荐的存储引擎。MyISAM在MySQL 5.5之前曾为默认引擎，但因不支持事务、崩溃恢复能力弱、表级锁并发差等缺陷，已被InnoDB全面取代。实践中，除极少数只读归档（如旧数据导出）场景外，绝大多数业务都应优先选择InnoDB。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 LGQ的博客！