临时表仅对当前会话可见且连接断开即销毁；可同名共存、遮蔽永久表、不显示于SHOW TABLES；引擎可选但非默认内存，事务支持取决于引擎；勿与MEMORY永久表混淆，亦不可跨请求依赖。
临时表只对当前会话可见，关掉连接就自动消失
这是最核心的区别：你用 CREATE TEMPORARY TABLE 创建的表，哪怕名字和某个永久表一样（比如都叫 tmp_orders），其他连接也完全看不见它；而你自己这个连接一断开（QUIT、客户端崩溃、超时断连），这张表立刻被删得干干净净，连结构都不留。
- 不同会话可以同时创建同名临时表，互不干扰——这点在 Web 应用多用户并发场景里特别有用
- 临时表会「遮蔽」同名的永久表：你在当前会话执行
SELECT * FROM users，如果刚好建过CREATE TEMPORARY TABLE users，查到的就是临时表，不是库里的真实users - 用
SHOW TABLES看不到临时表，但可以用DESCRIBE tmp_orders或直接SELECT操作它
临时表能用 InnoDB/MyISAM/MEMORY，但默认不保证事务或内存存储
很多人误以为“临时表 = 内存表”，其实不是。临时表的引擎是你自己选的，默认取决于 default_storage_engine 配置，常见是 InnoDB。它可能写磁盘，也可能进内存——关键看数据量和配置参数。
- 如果用
ENGINE=MEMORY创建临时表，它才真正只存在内存中；否则像ENGINE=InnoDB的临时表，数据仍落盘（写入ibtmp1临时表空间） - 内存是否够用，受两个参数共同限制：
tmp_table_size和max_heap_table_size，取其中较小值。超过就自动转成磁盘临时表，性能断崖下跌 - InnoDB 临时表支持事务和行锁；MyISAM 临时表不支持事务，且表级锁——选错引擎可能在复杂逻辑里引发意外阻塞
持久化表要手动删，且所有会话都能读写，权限和索引都得管
一张 CREATE TABLE orders 建出来的表，只要没执行 DROP TABLE，它就在磁盘上一直躺着，MySQL 重启也不丢。但它带来的维护责任也重得多：
- 表结构变更（如加字段）需考虑线上 DDL 锁影响，尤其大表；而临时表改结构无风险
- 索引要自己建，统计信息要定期
ANALYZE TABLE，否则优化器可能选错执行计划 - 权限控制粒度更细：你可以给某用户
SELECT权限但不给INSERT，但临时表权限随会话绑定，不走 GRANT 系统 - 备份脚本默认包含它，如果误把中间计算表建成了永久表，可能污染备份集、拖慢恢复速度
别把 MEMORY 表当临时表用，也别把临时表当缓存使
这是最容易混淆的坑：CREATE TABLE cache_users ENGINE=MEMORY 是一张**永久存在的内存表**，所有连接都能看到，MySQL 重启后数据全丢但表还在；而 CREATE TEMPORARY TABLE tmp_users 即便用了 ENGINE=MEMORY，也只活到你这个连接结束。
- 想做会话级中间结果？用
CREATE TEMPORARY TABLE，别手抖漏掉TEMPORARY关键字 - 想做全局轻量缓存（如配置项、状态码映射）？用
ENGINE=MEMORY+ 永久表，但必须配好max_heap_table_size，并写好服务启动后初始化数据的逻辑 - 千万别用临时表存重要中间状态然后依赖它跨请求——HTTP 请求之间连接通常不复用，临时表早没了
临时表的“自动清理”听着省心，但一旦忘了它只活于当前连接，就容易在连接池、长事务、异步任务里踩空——比如用连接池取到的连接不是你建表的那个，查 tmp_xxx 就直接报错 “Table doesn’t exist”。
