临时表是会话私有、自动清理、支持事务与多种引擎的中间结果暂存工具；内存表是全局共享、重启丢失、仅内存存储、默认HASH索引且不支持事务的高速缓存表。
临时表和内存表不能混用，选错一种可能让查询变慢十倍，甚至触发OOM崩溃。
临时表适合会话隔离、复杂中间计算
临时表本质是“会话私有草稿纸”，CREATE TEMPORARY TABLE 创建后只对当前连接可见，断开即删，不用手动清理。它支持 InnoDB 和 MyISAM 引擎，意味着能用事务、行锁、B+树索引，也能做 GROUP BY、ORDER BY、多表 JOIN 等重操作。
- 当数据量超过
tmp_table_size或max_heap_table_size的较小值时，MySQL 会自动把临时表落盘（变成磁盘表），不报错但性能陡降 - 在存储过程中反复建/查/删临时表很安全，不同会话同名临时表完全互不影响
-
SHOW CREATE TABLE查不到临时表，SELECT * FROM information_schema.tables也看不到，调试时容易误以为“没建成功” - binlog 记录行为取决于
binlog_format：设为ROW时不写 binlog；设为STATEMENT时会写，主从同步可能出问题
内存表适合全局高频读、小数据缓存
内存表是“共享速记本”，CREATE TABLE ... ENGINE=MEMORY 创建后所有会话都可读写，结构存磁盘（.frm 文件），数据全在内存。它默认用 HASH 索引，查主键或等值条件飞快，但不支持范围查询、ORDER BY、TEXT/BLOB 字段。
- 一旦插入数据超过
max_heap_table_size，直接报错ERROR 1114 (HY000): The table is full，不会自动降级到磁盘 - MySQL 重启后数据全丢，但表结构还在——如果没配定期备份机制，等于白建
- 所有会话共用同一份数据，写操作要靠表级锁，高并发写入时会卡住
- 内存表不参与事务，
ROLLBACK对它无效，INSERT后立刻可见，不适合需要 ACID 的场景
临时表也能用 MEMORY 引擎，但限制更多
你可以显式指定 CREATE TEMPORARY TABLE ... ENGINE=MEMORY，但这不是“内存表”，仍是临时表——只是把引擎换成了 MEMORY。此时它同时受两个参数约束：tmp_table_size 和 max_heap_table_size，取其中较小值为上限。
- 这种组合适合单次会话内需高速处理中等规模（几万行以内）、且不希望落盘的中间结果
- 不能用
HASH索引做范围扫描，如果业务逻辑依赖WHERE id BETWEEN 100 AND 200，得换回InnoDB引擎 - 即便用了
ENGINE=MEMORY，它仍不支持TEXT字段，VARCHAR长度也不能超限制，否则建表失败
实际选型关键看三件事
别看文档说“内存快就选 MEMORY”，真正上线前必须盯死这三点：
- 数据是否跨会话共享？要共享 → 只能选内存表（或普通表），临时表天然隔离
- 单次数据量会不会超
max_heap_table_size？超了 → 必须用临时表 +InnoDB，否则查询直接失败 - 有没有事务一致性要求？有 → 内存表排除，只能用
InnoDB临时表或普通表
最容易被忽略的是：内存表的 HASH 索引在 WHERE 条件含 >、<、LIKE '%abc' 时完全失效，查询走全表扫描——这时候你以为的“秒级响应”，实际比磁盘临时表还慢。
