临时表删不掉是因为未加TEMPORARY关键字，创建的是普通表；真正临时表仅当前连接可见且会话结束自动销毁，跨连接不可见，需用DROP TEMPORARY TABLE手动清理。
临时表为什么删不掉？TEMPORARY 关键字漏了就留坑
MySQL 里建的临时表，如果没加 TEMPORARY 关键字，它就不是临时表——而是普通表，会一直留在数据库里，直到你手动 DROP TABLE。很多人执行 CREATE TABLE my_temp AS SELECT ... 后以为会话结束自动消失，结果第二天发现表还在，还占着磁盘空间。
真正靠会话自动销毁的，只有一种：显式声明为临时表。其他所有“看起来像临时”的命名（比如带 _tmp、temp_ 前缀），对 MySQL 来说毫无意义。
-
CREATE TEMPORARY TABLE tmp_user SELECT * FROM user LIMIT 100;→ 会话断开后自动删除 -
CREATE TABLE tmp_user SELECT * FROM user LIMIT 100;→ 永久存在，必须DROP TABLE tmp_user; - 同一会话中可重复创建同名
TEMPORARY表，旧表被隐式丢弃；普通表则报错Table 'tmp_user' already exists
临时表能跨连接访问吗？CONNECTION 隔离是硬规则
临时表只在当前连接（connection）内可见，别的会话连 SHOW TABLES 都看不到它，更别说 SELECT 或 DROP。这不是权限问题，是 MySQL 的底层设计：每个连接维护独立的临时表命名空间。
所以别指望用一个连接建临时表，另一个连接去查——哪怕两个连接用的是同一个账号、同一台客户端，也完全不可见。常见误操作是写脚本时开了多个子进程或线程，各自建了同名临时表，彼此互不影响，但也无法共享。
- 存储过程里建的
TEMPORARY表，调用结束后不会自动删，得等整个连接断开 - PHP 的
mysqli或 Python 的pymysql中，只要没显式close()连接，临时表就一直活着 - 连接池场景下尤其危险：连接被复用，上一个请求建的临时表可能还在，导致后续
CREATE TEMPORARY TABLE报错Table 'xxx' already exists
临时表数据要不要手动清理？DROP TEMPORARY TABLE 通常没必要
只要连接正常关闭（包括客户端异常断开、超时断开、服务端 kill 连接），MySQL 会保证所有该连接的临时表被立即清理。手动执行 DROP TEMPORARY TABLE tmp_xxx; 只在两种情况下有用：想提前释放内存/磁盘资源，或者避免重名冲突（比如循环中反复建同名临时表）。
但要注意：DROP TEMPORARY TABLE 只能删临时表，如果误写成 DROP TABLE，而目标表恰好是普通表，就会真删掉它——没有回收站，不可逆。
- 推荐写法：
DROP TEMPORARY TABLE IF EXISTS tmp_log;（加IF EXISTS防错） - 禁止写法：
DROP TABLE tmp_log;（万一tmp_log是普通表，就全完了） - 临时表不支持
TRUNCATE，只能DROP或覆盖重建
临时表和磁盘临时表是一回事吗？tmpdir 和 MEMORY 引擎影响性能
临时表默认使用 MEMORY 引擎（内存表），但如果数据量超过 max_heap_table_size 或包含 TEXT/BLOB 字段，MySQL 会自动转存到磁盘，用 MyISAM（5.7）或 InnoDB（8.0+）引擎，并写入 tmpdir 目录。这时候“临时”只剩生命周期，物理文件已落地。
这意味着：大结果集的临时表可能产生大量磁盘 I/O，且 tmpdir 空间不足会导致查询失败，错误信息类似 Can't create/write to file '.../#sql_*.MYD' (Errcode: 28)。
- 检查当前设置：
SHOW VARIABLES LIKE 'tmpdir';、SHOW VARIABLES LIKE 'max_heap_table_size'; - 临时表不走查询缓存，也不被
mysqldump备份，但会记录到 binlog（除非binlog_format=STATEMENT且用了非确定函数） - 不要把
tmpdir挂在根分区，尤其当GROUP BY或ORDER BY涉及大数据量时，容易撑爆磁盘
临时表的“自动销毁”只绑定连接生命周期，跟 SQL 执行是否成功、事务是否提交、甚至客户端是否优雅退出都无关。最容易被忽略的是连接池复用和长连接场景——你以为的“临时”，可能已经悄悄活过三天。
