临时表仅当前会话可见、连接断开即销毁，支持多会话同名互不干扰、可遮蔽同名持久表；memory表是持久化结构+内存数据，所有会话共享、重启丢数据、不支持事务。
别用 MyISAM 做临时数据存储——除非你明确需要全文索引且能接受表锁阻塞，否则 Memory 引擎更合适，但必须注意它不支持事务、重启即丢数据、且受 max_heap_table_size 限制。
Memory 表为什么常被误当作“临时表”用？
很多人看到 CREATE TABLE ... ENGINE=MEMORY 就以为这是“临时表”，其实不是：Memory 是一种**持久化表结构 + 内存数据**的引擎，只要没手动 DROP TABLE，表定义一直存在，只是数据在内存里、服务重启就清空。它没有会话隔离性，所有连接都能访问同名 Memory 表（除非加前缀或命名区分），这点和 CREATE TEMPORARY TABLE 完全不同。
常见错误现象：
- 多个会话往同一个 tmp_user_cache（Memory 引擎）写数据，互相覆盖；
- 重启 MySQL 后应用报 Table 'tmp_user_cache' doesn't exist —— 实际是表还在，但数据空了，而代码逻辑误判为表缺失；
- INSERT 突然失败，报错 The table is full，其实是 max_heap_table_size 被突破，而非磁盘满。
使用建议：
- 仅用于单会话内短期中间计算（如报表聚合前的缓存），且必须显式 DROP TABLE 清理；
- 若需跨会话共享只读缓存，可接受丢失风险，才考虑 Memory；
- 永远不要依赖 Memory 表做状态持久化（比如用户登录 session 存储）。
MyISAM 临时表在什么场景下真有用？
MyISAM 本身不是为临时数据设计的，但它在特定只读分析场景中仍有价值：比如你有一张百万级静态维度表（如地区编码表、商品类目树），需要频繁 JOIN 但几乎不更新，又不想走 InnoDB 的 MVCC 开销和聚簇索引冗余。这时建一张 MyISAM 表，配合 CREATE TEMPORARY TABLE ... ENGINE=MyISAM 在会话内复用，比每次从磁盘读原表更快——因为 MyISAM 的非聚簇索引 + 简单文件结构，在纯顺序扫描时有优势。
但要注意：
- CREATE TEMPORARY TABLE 默认用 InnoDB（MySQL 8.0+），要显式指定 ENGINE=MyISAM 才生效；
- MyISAM 不支持事务，所以临时表里的操作无法回滚；
- 如果临时表要写入大量数据，MyISAM 的表级锁会让并发插入变成串行，性能反而比 InnoDB 临时表差；
- MySQL 8.0 已移除 MyISAM 系统表支持，部分运维工具对 MyISAM 临时表兼容性变弱。
真正该用哪种“临时数据载体”？看这三点
选型不能只看“快不快”，得盯住三个硬约束：
- 是否需要事务一致性？→ 必须选
CREATE TEMPORARY TABLE ... ENGINE=InnoDB（默认行为） - 数据量是否稳定小于
tmp_table_size和max_heap_table_size中的较小值？→ 满足则 InnoDB 临时表大概率走内存，无需额外干预 - 是否需要全文检索且数据完全静态？→ 才考虑
CREATE TEMPORARY TABLE ... ENGINE=MyISAM，否则绕开
示例对比：
- 错误用法：CREATE TABLE tmp_search ENGINE=MEMORY SELECT * FROM articles WHERE MATCH(title) AGAINST('MySQL'); → Memory 不支持全文索引，直接报错 Fulltext index is not supported for MEMORY engine
- 正确替代：CREATE TEMPORARY TABLE tmp_search ENGINE=MyISAM AS SELECT * FROM articles WHERE title LIKE '%MySQL%';（放弃全文，换模糊匹配）
容易被忽略的配置陷阱
Memory 和 MyISAM 临时表都严重依赖两个参数，但它们作用方式完全不同：
-
tmp_table_size：控制 **InnoDB/MyISAM 临时表**何时从内存转磁盘。超过此值，MySQL 自动把临时表写到磁盘（ibtmp1或系统临时目录），不影响语句执行，但性能下降 -
max_heap_table_size：控制 **Memory 引擎表**的最大容量。超过即报错The table is full，不会降级，也不会告警，应用必须捕获并处理
这两个值默认都是 16MB，但生产环境常需调大。关键是：它们互不影响，改一个不等于另一个也变。很多线上事故就是只调了 tmp_table_size，结果 Memory 表依然频繁报满，却以为“临时表配置已经加大了”。
最后提醒一句：MySQL 8.0+ 的优化器对内存临时表（无论引擎）的统计信息更敏感，如果用 Memory 表做 JOIN 中间结果，记得在 INSERT 后执行 ANALYZE TABLE，否则可能选错执行计划。
