只讲工作中真会用到的：InnoDB、MyISAM、MEMORY、Archive、OceanBase，其他忽略不用记。

一、总览核心对比表

引擎	事务	行锁 / 表锁	外键	崩溃恢复	适合场景
InnoDB	支持	行级锁	支持	支持	业务主力表、90% 生产场景
MyISAM	不支持	表级锁	不支持	不支持	只读静态表、老项目遗留
MEMORY	不支持	表级锁	不支持	不支持	临时缓存、临时计算表
Archive	不支持	表级锁	不支持	支持	日志归档、只插不删改
OceanBase	分布式事务	分布式 MVCC	不支持	强容灾	海量数据、高并发分布式替代 MySQL

二、逐个引擎优缺点详解

1. InnoDB（默认、生产首选）

✅ 优点

1. 支持 ACID 事务、Commit/Rollback
2. 行级锁，并发读写性能高
3. 支持 外键、主键、聚簇索引
4. 支持崩溃自动恢复、MVCC 多版本并发
5. 生态最成熟、兼容最好、运维资料多
6. 支持热备份、主从复制

❌ 缺点

1. 大数据量高并发写入有单机瓶颈
2. 随机写多，大批量插入速度不如 LSM 架构
3. 占用空间比 MyISAM 稍大
4. 不适合超大规模万亿级单表

适用：所有业务表、订单、用户、基础资料、后台系统，新项目一律用 InnoDB

---

2. MyISAM（老引擎，新项目禁止用）

✅ 优点

1. 结构简单、占用磁盘空间小
2. 查询速度极快，只读场景性能好
3. 全文索引支持比老 InnoDB 友好

❌ 缺点

1. 不支持事务，出错不能回滚
2. 表级锁，一写全表阻塞，并发差
3. 不支持外键
4. 崩溃容易数据损坏、修复麻烦
5. 不支持事务隔离级别

适用：静态字典、极少修改的配置表，新项目直接弃用

---

3. MEMORY（内存引擎）

✅ 优点

1. 全数据放内存，读写极速
2. 结构简单，无磁盘 IO

❌ 缺点

1. 重启 MySQL 数据全部丢失
2. 不支持事务、外键、大字段
3. 表级锁，并发一般
4. 受内存大小限制，不能存大数据

适用：临时中间表、接口缓存、临时统计

---

4. Archive（归档引擎）

✅ 优点

1. 超高压缩比，省磁盘
2. 插入性能极好
3. 只允许插入和查询，结构极简

❌ 缺点

1. 不支持更新、删除
2. 无索引（只能全表查）
3. 不支持事务、外键

适用：系统日志、操作日志、审计日志归档

---

5. OceanBase（分布式替代引擎，兼容 MySQL）

✅ 优点

1. 原生分布式，不用分库分表，水平无限扩容
2. LSM-Tree 顺序写，高并发写入远超 InnoDB
3. 多副本强容灾、两地三中心
4. 超高数据压缩，节省存储
5. 兼容 MySQL 语法，迁移改造成本低
6. 单表支持百亿 / 万亿级数据

❌ 缺点

1. 不支持外键，必须业务层做关联约束
2. 小众语法、存储过程、函数有兼容差异
3. 运维架构复杂，学习成本高
4. 简单小查询性能略逊原生 InnoDB
5. 自增、批量导入、sql_mode 有细微适配差异

适用：金融、大型集团、海量数据、高并发、未来数据暴涨，用来替代传统 MySQL 分库分表

---

三、职场选型口诀（直接照抄用）

1. 普通业务、管理系统、中小数据量 → InnoDB
2. 只读静态老数据、遗留系统 → MyISAM
3. 临时缓存、临时计算 → MEMORY
4. 日志流水、只存不改 → Archive
5. 海量数据、高并发、不想分库分表 → OceanBase

---

四、给你最简结论

• 日常开发 只认准 InnoDB
• 只有大数据、分布式架构才考虑 OceanBase
• 其他引擎基本都是历史遗留或特殊小众场景，新项目不用碰。