MySQL 从零到一(05):存储引擎选择
2026-10-12 09:40:00
一、什么是存储引擎?
如果把 MySQL 比作一个餐厅,存储引擎就是厨房的”炒菜方式”——同样一道菜(SQL),不同的存储引擎用不同的方式来”存”和”取”数据。
MySQL 的设计是”可插拔存储引擎”,SQL 解析、连接管理这些都是通用的,数据怎么存、怎么加锁、支不支持事务,由引擎决定。
1 | -- 查看当前 MySQL 支持的所有引擎 |
二、InnoDB vs MyISAM:最重要的对比
在 MySQL 5.5 之前,MyISAM 是默认引擎,主打读速度快。但互联网业务发展之后,订单、支付、库存都需要事务,InnoDB 逐渐成为主流,5.5 起成为默认。
| 对比维度 | InnoDB | MyISAM |
|---|---|---|
| 支持事务 | ✅ 支持 | ❌ 不支持 |
| 锁的粒度 | 行锁(并发更好) | 表级锁(写时整张表锁住) |
| 崩溃恢复 | 自动通过 Redo Log 恢复 | 需要手动修复,风险高 |
| 外键约束 | ✅ 支持 | ❌ 不支持 |
| 索引结构 | 聚簇索引(主键和数据在一起) | 非聚簇(数据另存) |
| 适用场景 | 订单、用户、任何需要事务的 | 历史归档只读、极少数特殊场景 |
结论:新项目一律用 InnoDB,没有理由用 MyISAM。
1 | -- 查看数据库里每张表用的是什么引擎 |
三、InnoDB 为什么并发更好?
MyISAM 写数据时锁整张表,同一时间只有一个写操作能进行。想象一下,一个大教室,每次只允许一个人进去写黑板,其他人全部在门外等。
InnoDB 用行级锁,只锁住被修改的那一行。不同的人修改不同的行,可以同时进行,并发能力大幅提升。
四、其他引擎:什么场景用什么
Memory 引擎:数据存在内存里
- 特点:极快,但重启后数据消失
- 适用场景:临时统计、小型缓存、会话数据
- 不适合:持久化数据,不能替代 Redis
1 | -- 临时统计表:只在当前会话有效,连接断了自动删除 |
CSV 引擎:数据存成 CSV 文件
- 特点:文件可以直接用 Excel 打开,便于交换
- 适用场景:需要把数据导出给其他系统用
- 不适合:正常业务表,因为没有索引
Archive 引擎:压缩存储
- 特点:数据高度压缩,只能插入和查询,不能更新
- 适用场景:日志归档、审计记录
- 不适合:需要频繁更新的数据
五、如何选择存储引擎?
1 | 需要事务吗? |
即使不需要事务,InnoDB 的行锁和崩溃恢复也比 MyISAM 可靠,所以通用选 InnoDB 准没错。
常见误区提醒
整个库只能用一种引擎:不对,每张表可以单独指定引擎。但要注意,跨引擎的操作无法在同一个事务里保证原子性。
MyISAM 读更快,所以读多写少的场景用 MyISAM:这个说法早就过时了。现代 InnoDB 的 Buffer Pool、MVCC 让普通读性能差距极小,而 InnoDB 还能做并发写和事务。
Memory 引擎可以替代 Redis:Memory 里的数据服务器一重启就没了,还占用 MySQL 连接,不适合做应用层缓存。
本章核心总结
- 存储引擎决定数据怎么存、怎么锁、支不支持事务
- InnoDB 支持事务+行锁+崩溃恢复,是现代业务的标准选择
- Memory 存内存、CSV 存文件、Archive 做归档,都是特殊场景
- 默认选 InnoDB,没有充分理由不换
下一步学习建议
存储引擎搞清楚了,下一篇进入最重要的性能话题——索引:为什么加了索引查询快 100 倍?B+Tree 是什么?回表是什么?