MEMORY表适合短生命周期、高读写频次的中间计算场景，如报表聚合前的中间汇总、JOIN缓冲、去重ID列表、会话级缓存；但不可用于持久化，且建表须指定MAX_ROWS。
MEMORY 表适合哪些中间计算场景
MENU 表只存于内存，无磁盘 I/O，适合短生命周期、高读写频次的临时结果。比如报表聚合前的中间汇总、JOIN 缓冲、去重 ID 列表、会话级缓存等。但一旦 MySQL 重启，所有数据丢失，所以绝不能用于持久化或关键中间状态。典型误用是把 GROUP BY 后的大结果集塞进 MEMORY 表再反复查——这反而因内存膨胀拖慢整体性能。
建表时必须显式指定 MAX_ROWS 和 KEY
MEMORY 引擎默认使用哈希索引，不支持范围查询（BETWEEN、 等），且不自动优化主键。若需 ORDER BY 或范围扫描，得手动建 <code>BTREE 索引：
CREATE TABLE tmp_sales ( product_id INT, total_amt DECIMAL(10,2), KEY idx_pid (product_id) USING BTREE ) ENGINE=MEMORY MAX_ROWS=1000000;
没设 MAX_ROWS 会导致插入超限时静默失败；没建合适索引会让 WHERE product_id = ? 变成全表扫描，比 InnoDB 还慢。
-
MAX_ROWS应按预估行数 × 单行大小（估算）反推，避免触发MEMORY table is full错误 - 字符串字段尽量用
CHAR而非VARCHAR，减少内存碎片 - 避免
TEXT/BLOB类型——MEMORY 不支持
与 InnoDB 中间表对比：不是越快越好
在复杂 JOIN 或多轮子查询中，InnoDB 临时表（由 tmp_table_size 和 max_heap_table_size 控制）可能自动落盘，而 MEMORY 表强制驻留内存。但这不意味着它更快：
- 当数据量超过
max_heap_table_size，InnoDB 会切到磁盘临时表，MEMORY 则直接报错The table is full - MEMORY 不支持事务和行锁，高并发写入易阻塞，而 InnoDB 临时表可并发读写
- 对含
ORDER BY+LIMIT的中间结果，InnoDB 利用排序缓冲区更稳，MEMORY 若没建 BTREE 索引，ORDER BY成为瓶颈
实测：10 万行数值聚合，MEMORY 比 InnoDB 快约 1.8 倍；但加了字符串分组和二级排序后，InnoDB 反而快 12%，因为 MEMORY 的哈希索引无法加速 ORDER BY name。
替代方案比硬上 MEMORY 更可靠
多数“加速中间计算”的需求，其实更适合用其他方式：
- 用
WITHCTE（MySQL 8.0+）避免物化，让优化器决定是否缓存 - 对固定维度聚合，建好覆盖索引的 InnoDB 表，配合
SQL_BUFFER_RESULT强制物化 - 用 Redis 存高频中间结果，尤其跨请求复用场景
- 真正需要内存速度又怕丢数据？考虑
TEMPORARY TABLE+ InnoDB，会话结束自动删，且支持完整事务
MEMORY 表的可控性远低于表面看起来的那样——内存分配、锁行为、索引类型都得手把手管着，稍不注意就从加速变成卡点。
