memory表查得快却不能替代innodb，因其快依赖三个硬前提：数据全驻内存、行长度固定、仅支持表级锁；超max_heap_table_size会报错，varchar按最大长度分配内存，高并发写入易阻塞，不支持text/blob，hash索引不支持范围查询，重启即丢数据且无可靠恢复机制。
MEMORY 引擎不是“快就能用”，而是“快但有硬限制”——它只适合明确知道数据可丢、并发写少、查询模式简单、且内存可控的临时场景。
为什么 MEMORY 表查得快，却不能替代 InnoDB？
因为它的快建立在三个不可妥协的前提上：数据全驻内存、行长度固定、只支持表级锁。这意味着：
-
SELECT不走磁盘 I/O，毫秒级响应常见，但一旦max_heap_table_size被突破，INSERT 会直接报错ERROR 1114 (HY000): The table 'xxx' is full - 哪怕定义
VARCHAR(255)，也会按 255 字节分配内存，空字段也占满——DATA_LENGTH值往往远大于实际数据体积 - 所有写操作（INSERT/UPDATE/DELETE）都会触发表级锁，高并发写入时容易卡住，和 InnoDB 的行级锁完全不是一个量级
- 不支持
TEXT、BLOB、JSON（MySQL 8.0+ 虽允许声明，但实际建表会失败或静默转为VARCHAR）
MEMORY 表的索引类型怎么选？HASH 还是 BTREE？
默认用 HASH 索引，但必须手动指定 BTREE 才能支持范围查询——否则 WHERE id BETWEEN 100 AND 200 会全表扫描。
- HASH 索引只加速等值查询（
=、IN），对、<code>>、LIKE 'abc%'无效 - BTREE 索引支持范围、排序、前缀匹配，但性能略低于 HASH；建索引时必须显式写
USING BTREE，例如：INDEX idx_created (created_at) USING BTREE - 主键默认也是 HASH，若需按主键范围扫描，必须声明
PRIMARY KEY (id) USING BTREE - 同一个字段不能同时建 HASH 和 BTREE 索引，会报错
ERROR 1061 (42000): Duplicate key name
重启后数据丢失，有没有补救办法？
没有真正可靠的“自动恢复”，所谓“持久化”只是权宜之计：
- 可以用
--init-file=/path/to/init.sql启动参数，在 mysqld 启动时重放 SQL 插入原始数据，但要求 init.sql 必须绝对可靠、幂等、且不依赖外部状态 - 不能依赖
mysqldump导出后再导入——因为 dump 文件里不含ENGINE=MEMORY，默认会建为 InnoDB，失去意义 - 更现实的做法是：把 MEMORY 表当“缓存层”，业务侧主动维护一份落盘副本（比如定期 INSERT INTO … SELECT … 到 InnoDB 表），而非指望数据库自己恢复
- 监控
SHOW TABLE STATUS中的Data_length + Index_length，持续接近max_heap_table_size就该预警，避免突发 OOM 或写入失败
最常被忽略的一点：MEMORY 表的生命周期不是由 SQL 控制的，而是由 MySQL 实例生命周期绑定的。哪怕你 DROP TABLE，那块内存也不会立刻归还给操作系统——它只在表被删且无其他连接引用时，才逐步释放。所以长期运行的服务中，频繁创建/删除 MEMORY 表反而可能造成内存碎片累积。
