InnoDB是MySQL 5.5+默认且首选引擎，适用于需事务、外键、高并发写入及崩溃自动恢复的场景；MyISAM仅适合只读静态表；MEMORY用于临时数据；ARCHIVE和CSV各限于归档与迁移等窄场景。
InnoDB 是什么场景下的默认且首选
只要你的表需要事务（比如转账、订单状态变更）、要保证多条 SQL 要么全成功要么全回滚，或者有外键约束、高并发写入、崩溃后能自动恢复——InnoDB 就不是“可选”，而是事实标准。MySQL 5.5+ 默认引擎就是它，不是偶然。
实操建议：
- 新建表不显式指定 ENGINE，就是 InnoDB；
- 切忌在生产环境把 InnoDB 表改成 MyISAM 来“提速”，丢了事务和行锁，反而在并发更新时卡死；
- 注意 innodb_file_per_table=ON（默认开启），否则所有表数据挤在共享表空间里，单个大表删不掉磁盘空间；
- SELECT COUNT(*) 慢？别怪引擎，InnoDB 不存行数，这是设计使然，用近似值或加汇总表替代。
MyISAM 为什么现在基本只用于“只读静态表”
它快，是真的快——尤其是全表扫描、大批量 INSERT、全文索引（早期比 InnoDB 更成熟）。但它不支持事务、用表级锁、宕机易损坏、不能热备。所以今天还在用它的，基本只剩两类：系统字典表（如权限表 mysql.user 在旧版本中）、历史归档的只读报表表。
常见错误现象：
- 突然发现 UPDATE 把整张表锁住，其他查询全部阻塞 → 典型 MyISAM 表级锁；
- 服务器异常重启后，SELECT 报错 Table is marked as crashed → 必须 REPAIR TABLE，而 InnoDB 自动恢复；
- OPTIMIZE TABLE 频繁执行 → 动态表碎片多，但修复过程会锁表，线上慎用。
MEMORY 引擎不是“加速器”，而是“临时工”
MEMORY 表所有数据都在 RAM 里，读写飞快，但服务一重启，数据全丢，表结构还在。它唯一合理用途是：临时中间结果、会话级缓存、快速去重（DISTINCT + GROUP BY 的中间集）。
容易踩的坑：
- 把用户 session 数据存在 MEMORY 表里 → 重启后全员登出，且无法持久化；
- 字段含 TEXT 或 BLOB → MySQL 自动退化成磁盘 MyISAM 临时表，性能断崖下跌；
- VARCHAR(255) 实际按最长长度分配内存 → 浪费严重，改用 CHAR 要谨慎权衡；
- 内存爆满报错 ERROR 1114 (HY000): The table 'xxx' is full → 调大 max_heap_table_size，但别无脑设 GB 级，会挤占 buffer pool。
Archive 和 CSV 这类专用引擎，用错就等于自找麻烦
ARCHIVE 压缩率高、插入极快、只支持 INSERT 和 SELECT，适合日志归档；CSV 直接映射为文本文件，方便 Excel 打开或 ETL 导入导出。但它们都不支持索引（ARCHIVE 仅支持主键）、不支持事务、不能 UPDATE/DELETE（CSV 可删但不推荐）。
使用场景很窄：
- ARCHIVE：审计日志表，写一次、查极少、长期存；
- CSV：一次性数据迁移，或给非技术人员提供“打开即见”的报表；
- 别用 ARCHIVE 存订单明细想“省空间” → 查一条要全表解压扫描，响应秒变分钟级；
- 别用 CSV 当业务表 → 文件被外部程序误改或编码错乱，MySQL 读出来全是乱码或截断。
真正做选型时，别先看“哪个快”，先问自己：这表会不会被并发修改？需不需要事务回滚？数据丢了能不能接受？备份策略是否覆盖它？——引擎不是性能开关，而是数据契约的落地形式。
