mysql数据库中的临时表与持久化表区别

临时表仅对当前会话可见且连接断开即销毁；可同名共存、遮蔽永久表、不显示于SHOW TABLES；引擎可选但非默认内存，事务支持取决于引擎；勿与MEMORY永久表混淆，亦不可跨请求依赖。

临时表只对当前会话可见，关掉连接就自动消失

这是最核心的区别：你用 CREATE TEMPORARY TABLE 创建的表，哪怕名字和某个永久表一样（比如都叫 tmp_ord

ers），其他连接也完全看不见它；而你自己这个连接一断开（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”。