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，适合生命周期短、追求极致响应的中间结果。
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载断电或重启后数据全丢，不能用于持久化存储默认哈希索引，等值查询（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。