临时表自动销毁由会话生命周期决定，连接关闭时立即清理；不显式DROP会导致同名复用失败、数据污染和资源延迟释放，且无法通过SHOW TABLES或information_schema查看。
临时表自动销毁是会话级生命周期决定的
MySQL 的 CREATE TEMPORARY TABLE 不是“临时”在语义上，而是严格绑定到**当前数据库连接（session）**。只要这个连接没断，临时表就一直存在；一旦连接关闭（比如客户端退出、PHP 脚本执行结束、连接池中连接被归还并显式关闭），MySQL 就立即清理该会话下所有临时表——结构和数据一并抹掉，不残留任何元数据。
为什么 DROP TEMPORARY TABLE 不是必须但强烈建议
不显式 DROP TEMPORARY TABLE 不会导致内存泄漏或服务异常，但会引发两类实际问题：
- 同名复用失败：下次再
CREATE TEMPORARY TABLE t1时直接报ERROR 1050 (42S01): Table 't1' already exists - 连接复用场景下的数据污染：例如 Java 应用使用 Druid 连接池，同一个物理连接可能被多个业务请求复用；若前一个请求建了
t1但没删，后一个请求误读t1里的旧数据，就会出逻辑错误 - 资源未及时释放：大结果集写入临时表后，即使存储过程已返回，
tmp_table_size占用的内存可能不会立刻归还，影响后续查询缓冲区分配
SHOW TABLES 看不到临时表，但 SHOW CREATE TABLE 能查到
SHOW TABLES 故意过滤掉临时表，这是设计行为，不是 bug。验证临时表是否存在，应该用：
SHOW CREATE TABLE <table_name>;
如果返回 Table 'xxx' doesn't exist，说明它已被销毁；如果返回建表语句，说明它还在当前会话中存活。注意：不能用 SELECT * FROM information_schema.TABLES 查临时表——它们根本不出现在 information_schema 里。
连接没断但内存持续上涨？检查 SQL_BUFFER_RESULT 和参数配置
临时表本身不显示在 SHOW PROCESSLIST，但它的资源消耗会体现在状态变量中：Created_tmp_tables 和 Created_tmp_disk_tables 每次递增都代表一次新临时表创建。如果发现内存持续上涨且无明显连接断开：
- 确认是否在语句中加了
SQL_BUFFER_RESULT提示——它强制将结果物化进临时表，延迟释放时机 - 检查
tmp_table_size和max_heap_table_size是否相等；若不等，哪怕内存充足，也可能因阈值判断不一致导致临时表意外落盘，进而卡住磁盘 I/O 和内存缓冲 - 避免在存储过程循环体里反复
CREATE TEMPORARY TABLE ... SELECT；改用单次建表 +INSERT ... ON DUPLICATE KEY UPDATE或分批 INSERT
真正容易被忽略的是：临时表的“自动销毁”只对连接生命周期有效，而现代应用大量使用连接池、长连接、线程复用——这时候不手动 DROP，等于把命名空间和内存占用交给了不可控的连接回收策略。
