MySQL 8.0+ 已彻底移除 MyISAM 引擎，旧表需手动转为 InnoDB 或 Archive；InnoDB 是默认且唯一稳妥选择，需调优 buffer_pool_size 和 log_file_size；Archive 仅适用于纯只读归档；Memory 仅限临时计算，重启即失。
MyISAM 在 MySQL 8.0+ 里根本不能用
MySQL 8.0 默认禁用 MyISAM，连安装后首次启动都会在错误日志里报 Plugin 'MyISAM' is disabled。不是配置问题，是官方直接移除了加载逻辑。如果你的旧系统还依赖它，升级前必须把所有 ENGINE=MyISAM 表转成 InnoDB 或 Archive（只读归档场景）。否则 CREATE TABLE ... ENGINE=MyISAM 会静默降级为 InnoDB，但已有表不会自动转换，SHOW CREATE TABLE 看到的还是 MyISAM，实际已不可用。
InnoDB 是默认且唯一稳妥的选择
95% 的业务场景该无脑选 InnoDB——它支持事务、行锁、外键、崩溃恢复，而且从 MySQL 5.6 起就默认启用 innodb_file_per_table=ON，单表空间管理清晰。几个关键点要手动确认：
-
innodb_buffer_pool_size必须设为物理内存的 50%–75%，太小会导致频繁刷盘，太大挤占 OS 缓存 - 高并发写入时，
innodb_log_file_size建议调大（比如 1G），避免日志频繁切换引发Waiting for log write - 如果业务大量执行
SELECT COUNT(*)，别指望InnoDB给准确值——它不维护全表行数，得走聚簇索引扫描，慢是常态
Archive 引擎只适合冷数据归档
Archive 不是“轻量级 InnoDB”，它是纯压缩只读引擎，写入后无法 UPDATE/DELETE，也没有索引。典型误用是拿它存“历史订单”并试图加 WHERE user_id = ? 查询——结果只能全表解压扫描，比 InnoDB 还慢。它真正适用的场景只有一个：INSERT 一次、后续只 SELECT * FROM ... WHERE id IN (...) 批量导出，比如审计日志归档。
注意：Archive 表无法被 mysqldump 正常备份（会跳过），必须用 SELECT INTO OUTFILE 或物理拷贝 .ARZ 文件。
Memory 引擎只该用在临时计算表
Memory 引擎数据全在内存，重启即丢，且不支持 TEXT/BLOB 字段。常见错误是把它当缓存表用，比如建个 cache_user_profile 存用户资料——一旦 MySQL 意外退出或 OOM 被杀，数据全空，应用层没兜底就会报错。它唯一合理用途是：存储过程里做中间聚合，或者 CREATE TEMPORARY TABLE ... ENGINE=MEMORY 加速 JOIN。
还要小心 max_heap_table_size 和 tmp_table_size 两个参数，它们共同限制 Memory 表最大容量，超限会自动转成磁盘临时表，性能断崖下跌。
真正难的不是选哪个引擎，而是识别业务里那些“看起来像只读、其实要更新”“看起来量小、其实会爆炸增长”的表——这类表一旦选错引擎，后期迁移成本远高于初期多花半小时评估。
