临时表只对当前会话可见，关掉连接就自动消失
这是最核心的区别：你用
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”。
