该用 MEMORY 引擎时：数据可丢、体积可控（≤64MB）、仅作临时表/缓存/测试；不支持持久化、TEXT/BLOB、范围查询（HASH索引）、高并发写入，且重启即失。
什么时候该用 MEMORY 引擎？别只看“快”
memory 引擎把所有数据存在 ram 里，读写确实快，但一断电就全丢。它适合做临时中间表、缓存聚合结果、或者测试时快速跑逻辑——前提是数据可丢、体积可控（默认最大 64mb，由 max_heap_table_size 控制）。
常见错误是拿它存用户会话或订单草稿：重启 MySQL 后发现“数据消失了”，其实不是 bug，是设计如此。
- 不支持
TEXT或BLOB类型，建表时遇到ERROR 1071: Specified key was too long很可能是因为字段类型不兼容 - 表锁粒度粗，高并发写入时容易卡住，别当高频更新的主业务表用
- 索引只能是
HASH（默认）或BTREE，但HASH不支持范围查询（WHERE id > 100会全表扫）
CSV 引擎真能当“Excel 替代品”吗？
可以导出/导入简单表格，但仅限于纯数据交换场景。它的文件就是逗号分隔的文本（/var/lib/mysql/dbname/tbl.csv），你直接用 Excel 打开没问题，但 MySQL 对它几乎不做校验：插入非法日期、超长字符串、缺失字段都不会报错，只会静默截断或填空值。
典型误用是把它当轻量级日志表——结果某天发现 SELECT COUNT(*) 慢得离谱，因为每次查都要全文件扫描，且不支持索引。
- 不支持事务、不支持索引、不能有
NULL默认值（除非显式声明NULL） - 字段名必须是合法标识符，含空格或特殊字符会直接建表失败（
ERROR 1005: Can't create table） - 写入性能差，每行插入都触发一次磁盘写，比
InnoDB慢一个数量级
ARCHIVE 引擎只适合“塞进柜子再也不动”的数据
压缩率高、写入快、占用空间小，但只支持 INSERT 和 SELECT，不支持 UPDATE、DELETE、索引（除了自增 PRIMARY KEY）、甚至不支持 REPLACE。它是为归档日志、审计记录这类“写一次、查极少、永不改”的场景设计的。
有人想用它存历史订单，结果发现查某个月的订单要 30 秒——因为没有索引，只能解压+扫描全量数据。
- 查询性能取决于匹配行在文件中的物理位置，
WHERE条件越靠前字段（如时间戳），越可能提前终止解压 - 不支持事务，
INSERT是原子的，但批量插入中某行失败会导致整个语句回滚 - 表修复只能用
REPAIR TABLE，且仅限于修复压缩头损坏，数据损坏基本不可恢复
为什么别急着跳过 InnoDB 去选这些引擎？
绝大多数新表，只要需要事务、外键、崩溃恢复、或未来可能加索引/更新，InnoDB 仍是默认且最安全的选择。上面三个引擎不是“更轻量的替代”，而是“有明确残缺的专用工具”。比如 MEMORY 没持久化，CSV 没一致性保障，ARCHIVE 没更新能力——它们省掉的每个功能，都是你在某个深夜排查问题时才发现“原来这里不能用”的地方。
真正需要换引擎，往往是因为已有明确瓶颈：比如日志写入吞吐压垮了 InnoDB 的 redo log，才考虑 ARCHIVE；比如临时统计中间结果太大，内存又够，才切到 MEMORY。没到那个量级前，先用 InnoDB，别为“听起来高级”换引擎。
