MySQL 的存储引擎有哪些？它们之间有什么区别？

MySQL 存储引擎详解

【核心定义】

MySQL 存储引擎是数据库底层用于管理数据存储、索引实现、事务处理等核心操作的组件化架构，它决定了数据的物理存储结构和逻辑访问特性。

【关键要点】

InnoDB：MySQL 5.5 后的默认引擎，支持事务安全（ACID）、行级锁、外键约束，采用聚簇索引存储数据，适用于高并发、事务性应用。
MyISAM：MySQL 5.5 前的默认引擎，不支持事务和行锁，提供表级锁，支持全文索引，读取性能高，适用于读多写少、非事务场景。
MEMORY：数据完全存储在内存中，读写速度极快，但服务重启后数据丢失，适用于临时表或缓存场景。
Archive：高压缩比存储，只支持 INSERT 和 SELECT 操作，适用于日志归档等大量历史数据存储。
CSV：以 CSV 格式存储数据，可直接用文本编辑器查看，适用于数据交换场景。

【深度推导/细节】

核心架构差异对比

特性维度	InnoDB	MyISAM
事务支持	支持（ACID）	不支持
锁粒度	行级锁（默认）	表级锁
外键	支持	不支持
崩溃恢复	支持（redo log）	不支持
索引结构	聚簇索引（数据即索引）	非聚簇索引（索引与数据分离）
缓存机制	缓冲池（数据和索引）	只缓存索引

性能临界点设计原理

InnoDB 行锁升级：当单条 SQL 更新超过表的一定比例（通常约 20%）时，行锁可能升级为表锁，这是为了避免锁开销过大而设计的性能保护机制。
MyISAM 并发插入：支持并发插入（concurrent_insert），允许在表尾并发插入，但会阻塞其他写操作，这是其表锁架构下的优化策略。

【关联/对比】

InnoDB vs MyISAM 核心区别

事务与锁机制：
- InnoDB 通过 MVCC（多版本并发控制） 实现高并发，写操作加行锁时不影响其他行的读取。
- MyISAM 的表锁在写操作时会阻塞所有其他操作，读操作之间不互斥。
索引实现：
- InnoDB 的聚簇索引将数据行存储在索引的叶子节点，主键查询极快，但二级索引需要两次查找（先找主键，再找数据）。
- MyISAM 的非聚簇索引中索引和数据分离，所有索引查询都需要回表。
数据恢复：
- InnoDB 通过 redo log（重做日志） 和 undo log（回滚日志） 保证事务持久性和原子性。
- MyISAM 崩溃后可能产生数据损坏，需要修复表（REPAIR TABLE）。

版本演进差异

MySQL 5.5 之前：MyISAM 为默认引擎，适合 Web 应用快速读取。
MySQL 5.5 及以后：InnoDB 成为默认引擎，适应了互联网应用对事务和并发的要求。
MySQL 8.0：InnoDB 功能进一步增强，如原子 DDL、哈希索引优化，MyISAM 已逐渐边缘化。

『面试官追问』

为什么 InnoDB 推荐使用自增主键？
- 自增主键保证新数据顺序插入，避免页分裂，提升写入性能。
- 物理存储连续，减少磁盘随机 I/O，提高范围查询效率。
MyISAM 的全文索引和 InnoDB 的全文索引有何不同？
- MyISAM 的全文索引从早期版本就支持，但不支持中文分词。
- InnoDB 从 5.6 开始支持全文索引，基于倒排索引实现，支持插件化分词器。
什么场景下还会使用 MyISAM？
- 只读或读远大于写的业务（如数据仓库报表）。
- 不需要事务支持，且对空间占用敏感（MyISAM 压缩表空间占用更小）。
- 使用全文索引且版本低于 MySQL 5.6。
InnoDB 的缓冲池（Buffer Pool）如何工作？
- 缓冲池是内存区域，缓存数据和索引页。
- 采用 LRU 算法管理，分为 young 和 old 两个子列表，防止全表扫描污染热数据。
- 脏页通过 Checkpoint 机制异步刷回磁盘。
如何选择存储引擎？
- 需要事务或高并发更新 → InnoDB
- 只读或读多写少，且数据量巨大 → MyISAM（谨慎选择）
- 临时计算或缓存 → MEMORY
- 日志归档 → Archive

【总结】

MySQL 的存储引擎架构体现了插件化设计思想，InnoDB 凭借其事务安全性、高并发支持和崩溃恢复能力成为现代应用的首选。MyISAM 在特定读密集型场景仍有价值，但随着 MySQL 版本演进，其使用场景逐渐收窄。选择存储引擎时，必须结合业务的事务需求、并发模式和数据特性进行综合评估。

# MySQL 的存储引擎有哪些？它们之间有什么区别？