应优先选InnoDB，因其支持事务、行级锁、外键和崩溃自动恢复；MyISAM仅适用于只读或极少更新的归档场景；Memory仅作临时表；Archive适合写多查少的日志归档；第三方引擎运维成本高，多数场景无需替换。
MyISAM 和 InnoDB 哪个该用？看事务和崩溃恢复需求
MySQL 5.5 之后默认引擎是 InnoDB，不是因为性能压倒性优势，而是它支持事务、行级锁、外键和崩溃自动恢复——这些是生产系统的基本底线。如果你的应用需要 ROLLBACK、COMMIT 或者写操作频繁且并发高，InnoDB 是唯一合理选择。而 MyISAM 虽然在纯读场景下 COUNT(*) 快、索引体积小，但它不支持事务，崩溃后表容易损坏，修复需手动 REPAIR TABLE，且写操作会锁整张表。
- 高频更新/插入 + 多用户并发 → 必选
InnoDB - 日志类、归档表（只 insert，几乎不 update/delete）→
MyISAM可考虑，但更推荐InnoDB配合ROW_FORMAT=COMPRESSED - 全文检索早期依赖
MyISAM的FULLTEXT，但 MySQL 5.6+ 的InnoDB已完全支持，无需妥协
什么时候该考虑 Memory 引擎？别把它当缓存用
Memory 引擎把数据全放内存，读极快，但服务重启或崩溃就丢数据，且不支持 BLOB/TEXT 类型、无事务、表级锁。它适合做临时中间结果集，比如报表生成时的汇总暂存，或 JOIN 前的筛选缓存。
- 仅用于生命周期明确的临时表：
CREATE TEMPORARY TABLE ... ENGINE=MEMORY - 数据量不能超过
max_heap_table_size（默认 16MB），超限会静默转成磁盘表，引发隐式性能抖动 - 不要拿它替代 Redis 或应用层缓存——没有淘汰策略、无法跨连接共享、OOM 风险高
Archive 引擎真适合日志归档吗？先看查询模式
Archive 引擎专为“一次写入、极少查询”设计，用 zlib 压缩行，存储效率极高，但只支持 INSERT 和 SELECT，不支持索引（除主键外），WHERE 条件只能走全表扫描。
- 适合：审计日志、原始埋点数据、备份镜像等「写完就扔，查得少且宽泛」场景
- 不适合：需要按时间范围快速查某天错误日志 → 应该用
InnoDB+ 时间分区，或导出到 ClickHouse - 注意：
Archive表无法被mysqldump正常备份（会跳过），必须用SELECT INTO OUTFILE或物理拷贝.ARZ文件
自定义引擎如 TokuDB、RocksDB 还值得试吗？
TokuDB（已停止维护）和基于 RocksDB 的 MyRocks 曾主打高压缩比和高写吞吐，但它们带来额外运维成本：编译安装复杂、监控指标不标准、与 MySQL 官方版本兼容性差。除非你有 TB 级写密集型日志、且已有专职 DBA 深度调优能力，否则收益远低于代价。
- MySQL 8.0 的
InnoDB已支持原子 DDL、并行查询、更优的 Buffer Pool 刷新策略，多数场景不再输于 MyRocks -
ALTER TABLE ... ALGORITHM=INPLACE在InnoDB下已足够稳定，不必为“在线加字段”换引擎 - 第三方引擎的
SHOW ENGINE INNODB STATUS类诊断工具不可用，出问题时排查链路断裂
实际选型时，真正卡住性能的往往不是引擎本身，而是索引设计是否覆盖查询条件、JOIN 是否走了驱动表、GROUP BY 是否触发了临时表 —— 引擎只是底座，别让它替慢 SQL 背锅。
