MySQL存储引擎需按业务需求选择：InnoDB支持ACID事务、行级锁和崩溃恢复，适合高并发一致性场景；MyISAM仅表级锁且无事务，适用于只读归档；Memory引擎纯内存存储，断电丢失，适合临时计算；Archive专为高压缩冷数据归档设计，仅支持INSERT/SELECT。
MySQL 存储引擎不是“选一个就行”的配置项，而是直接影响数据安全、并发能力、查询速度和运维方式的核心设计选择。不同引擎在事务、锁、索引、崩溃恢复等关键维度差异明显，用错可能带来数据丢失、锁表卡顿或性能瓶颈。
InnoDB：高并发事务场景的默认主力
InnoDB 是 MySQL 5.5 之后的默认引擎，适合订单、账户、用户权限等对一致性要求高的业务。
- 支持完整 ACID 事务，能用 START TRANSACTION / COMMIT / ROLLBACK 控制逻辑单元，比如转账时两笔 UPDATE 必须同时成功或同时回滚
- 行级锁 + MVCC（多版本并发控制），多个用户更新不同行互不阻塞；SELECT 不加锁也能读到一致快照
- 强制支持外键约束，子表插入非法 dept_id 会被直接拒绝，避免脏关联数据
- 使用聚簇索引，主键值决定数据物理存储顺序，主键查询极快；但二级索引会额外存主键值，宽主键会增大索引体积
- 崩溃后靠 redo log（重做日志）和 undo log（回滚日志）自动恢复，无需人工干预
MyISAM：轻量只读或归档类场景的备选
MyISAM 已逐步退出主流业务表，但在某些特定场景仍有价值，比如静态内容库、历史日志快照、全文检索早期方案。
- 不支持事务，也没有崩溃恢复机制，服务器异常断电可能导致 .MYD 文件损坏
- 只有表级锁，一个 UPDATE 就会让整张表无法 SELECT，写多时并发能力差
- 索引与数据分离（.MYI 和 .MYD 文件），可单独复制索引文件，也方便直接拷贝备份
- 支持全文索引（虽然 MySQL 5.6+ 的 InnoDB 也已支持，但 MyISAM 的实现更轻量）
- 静态表结构下（无 VARCHAR/BLOB）读性能略高，适合 CMS 文章列表这类读远大于写的场景
Memory：纯内存临时计算的加速器
Memory 引擎所有数据驻留在 RAM，适合生命周期短、追求极致响应的中间结果。
- 断电或重启后数据全丢，不能用于持久化存储
- 默认哈希索引，等值查询（WHERE id = ?）飞快；但范围查询（BETWEEN、ORDER BY）效率低
- 只支持表级锁，高并发写入仍受限
- 常用于缓存热点维度表（如地区编码映射）、GROUP BY 中间聚合、JOIN 临时结果集
- 注意设置 max_heap_table_size，避免 INSERT 超出内存限制报错
Archive：低成本归档冷数据的专用通道
Archive 引擎专为“写一次、查极少”设计，主打高压缩比和低存储开销。
- 仅支持 INSERT 和 SELECT，不能 UPDATE/DELETE，天然防误改
- 数据自动 zlib 压缩，磁盘占用通常只有 MyISAM 的 10%–20%
- 无普通索引（只有自增主键），全表扫描是常态，不适合高频条件查询
- 典型用途：操作日志归档、审计记录沉淀、按月分表后的历史订单备份
- 配合事件调度器（EVENT）可自动将老数据迁入 Archive 表，释放主表压力
基本上就这些。选引擎不是看功能多不多，而是看业务最不能妥协的是什么——要事务？选 InnoDB；要快且不怕丢？考虑 Memory；要省空间且只查不改？Archive 更合适。实际项目中，一张库经常混合使用多种引擎，比如主业务表用 InnoDB，统计中间表用 Memory，三年前订单归档到 Archive。
