Mysql存储引擎

一、什么是存储引擎

可以把 MySQL 想象成一家"快递公司"：MySQL 服务器负责接单、派单（处理 SQL、连接管理），而存储引擎就是不同的"运输方式"——有的用飞机（快但贵），有的用卡车（便宜能装），有的用冷链车（保证货物不出问题）。

简单说：存储引擎就是 MySQL 底层真正负责"数据怎么存、怎么取"的组件。同一张表，用不同的存储引擎，数据的文件格式、索引方式、并发能力、是否支持事务都可能完全不同。

查看当前支持的存储引擎：

SHOW ENGINES;

查看某张表使用的引擎：

SHOW TABLE STATUS LIKE '表名';

建表时指定引擎：

CREATE TABLE user (
  id INT PRIMARY KEY,
  name VARCHAR(50)
) ENGINE = InnoDB;

二、常见存储引擎及特点

1. InnoDB（默认引擎，主角）

MySQL 5.5 之后的默认存储引擎，也是绝大多数业务的首选。

核心特点：

• 支持事务：支持 ACID 特性，配合 COMMIT、ROLLBACK 使用，保证数据不出错。比如转账场景，扣钱和加钱必须同时成功或同时失败。
• 支持行级锁：更新数据时只锁定涉及的那一行，多人同时操作不互相阻塞，并发性能高。
• 支持外键：可以在数据库层面维护表与表之间的关联完整性。
• 聚簇索引：数据和主键索引存放在一起，按主键查询速度非常快。
• 崩溃恢复：通过 redo log（重做日志），数据库意外宕机重启后能自动恢复未落盘的数据。
• 支持 MVCC（多版本并发控制）：读写不互相阻塞，普通 SELECT 不需要加锁。

2. MyISAM（老牌引擎，逐渐被淘汰）

MySQL 5.5 之前的默认引擎。

核心特点：

• 不支持事务：数据一致性没有保障。
• 只支持表级锁：哪怕只改一行，也要锁住整张表，写入并发一高就卡。
• 查询快：在"读多写极少"的纯查询场景下，曾经比 InnoDB 略快（现代 InnoDB 已没有明显差距）。
• 支持全文索引（早期优势，InnoDB 5.6 之后也支持了）。
• 文件结构简单：一张表对应 .frm（表结构）、.MYD（数据）、.MYI（索引）三个文件。

3. Memory（内存引擎）

• 数据全部存放在内存中，速度快到极致。
• 缺点：重启或宕机后数据全部丢失，且只支持表级锁。
• 适用：临时表、缓存类的中间结果。

4. Archive（归档引擎）

• 只支持 INSERT 和 SELECT，不支持更新和删除。
• 数据经过高比例压缩，非常省空间。
• 适用：日志、历史流水等"只写不查（偶尔查）"的归档数据。

5. CSV

• 数据以 CSV 文本格式存储，可以直接用 Excel 打开。
• 不支持索引，性能差，一般用于数据交换场景。

对比速查表

特性	InnoDB	MyISAM	Memory	Archive
事务	✅	❌	❌	❌
行级锁	✅	❌(表锁)	❌(表锁)	❌(行锁插入)
外键	✅	❌	❌	❌
崩溃恢复	✅	❌	❌	❌
数据持久化	✅	✅	❌(内存)	✅
全文索引	✅(5.6+)	✅	❌	❌

三、存储引擎怎么选

记住一句话：99% 的场景直接用 InnoDB，不需要纠结。

具体判断思路：

1. 需要事务吗？ 需要 → InnoDB（唯一选择）。涉及钱的业务（订单、支付、账户）必须 InnoDB。
2. 并发写入多吗？ 多 → InnoDB（行级锁）。MyISAM 表锁在高并发写入时是灾难。
3. 只是临时计算、丢了也无所谓？ → Memory。
4. 海量日志只存不改、想省空间？ → Archive。
5. 老系统还在用 MyISAM？ 建议逐步迁移到 InnoDB：

ALTER TABLE 表名 ENGINE = InnoDB;

四、MySQL 体系结构

MySQL 整体是分层架构，从下到上可以分为四层：

┌─────────────────────────────────────┐
│  第一层：连接层                        │
│  负责客户端连接、认证、线程管理          │
├─────────────────────────────────────┤
│  第二层：服务层（SQL 层）               │
│  连接器 → 分析器 → 优化器 → 执行器      │
│  以及缓存、内置函数、存储过程、视图等     │
├─────────────────────────────────────┤
│  第三层：存储引擎层                     │
│  InnoDB / MyISAM / Memory ...        │
│  （插件式架构，可插拔）                  │
├─────────────────────────────────────┤
│  第四层：文件系统层                     │
│  数据文件、索引文件、redo log、binlog   │
└─────────────────────────────────────┘

第一层：连接层

最上层，负责和客户端打交道：建立 TCP 连接、校验账号密码、分配线程。MySQL 为每个连接分配一个线程来处理请求。

第二层：服务层（核心大脑）

这一层是 MySQL 的"大脑"，所有跨存储引擎的功能都在这里实现。一条 SQL 的执行流程：

1. 连接器：验证权限，建立连接。
2. 查询缓存（MySQL 8.0 已移除）：查完全相同 SQL 的缓存结果。
3. 分析器：做词法、语法分析，识别出"你要查哪张表、哪些字段"。
4. 优化器：决定执行方案——用哪个索引、多表 JOIN 的顺序等，选出它认为最快的路径。
5. 执行器：调用存储引擎的接口，逐行取数据并返回。

关键点：这一层不关心底层用的是 InnoDB 还是 MyISAM，它只调用统一的引擎接口（handler API）。这正是存储引擎能"插拔"的原因。

第三层：存储引擎层

插件式架构，真正负责数据的存取。不同引擎各自实现数据的物理存储方式、索引结构、锁机制、事务支持。前文介绍的 InnoDB、MyISAM 等都属于这一层。

注意区分两个日志：

• redo log：InnoDB 引擎层独有的日志，保证崩溃恢复（数据不丢）。
• binlog：服务层的日志，记录所有修改操作，用于主从复制和数据归档。

第四层：文件系统层

最底层，把数据真正落到磁盘上：数据文件（.ibd）、索引文件、各种日志文件（redo log、binlog、undo log、慢查询日志等）。

五、一句话总结

• 存储引擎 = MySQL 的"数据存取方案"，可插拔。
• InnoDB 是绝对主流：事务、行锁、外键、崩溃恢复一应俱全。
• MySQL 分四层：连接层 → 服务层 → 引擎层 → 文件系统层，SQL 在服务层解析优化，交给引擎层执行，最终落盘到文件系统。