MySQL 临时表什么时候会消失：会话范围、事务提交与连接池复用

排查报表接口时，最容易误判的一件事是把临时表当成“事务结束就自动清空”的工作表。MySQL 的用户临时表实际绑定在创建它的客户端会话上：COMMIT 只结束事务，连接还在，表就还在；连接真正断开时，表才会被删除。

把临时表放进连接池时，必须把“事务清理”和“会话清理”分开设计：提交或回滚不能代替 DROP TEMPORARY TABLE。

先分清临时表、事务和连接的边界

下面这段 SQL 用于观察生命周期。两个客户端分别执行时，第二个客户端看不到第一个客户端创建的 tmp_order_ids；同一个客户端执行 COMMIT 后再次查询，表仍然存在。

CREATE TEMPORARY TABLE tmp_order_ids (
    order_id BIGINT PRIMARY KEY
);

INSERT INTO tmp_order_ids VALUES (101), (102);
COMMIT;
SELECT * FROM tmp_order_ids;

这里的关键不是 SQL 是否提交，而是连接是否还是同一个会话。MySQL 文档还特别说明，SHOW TABLES 不会列出这类临时表，所以不要用它判断临时表是否存在；直接查询临时表或查看会话中的创建逻辑更可靠。

可以把这个状态记成四个核对词：MySQL 会话 创建 tmp_order_ids，COMMIT 后仍存在，直到 断开连接后清理。

连接池复用时，归还连接前做一次会话清理

连接池把物理连接交给下一次请求时，数据库会话并没有重建。假设请求 A 创建并填充 tmp_order_ids，只执行了 ROLLBACK 就归还连接，请求 B 可能继续使用同名临时表，读到上一轮残留数据。

START TRANSACTION;
CREATE TEMPORARY TABLE tmp_order_ids (
    order_id BIGINT PRIMARY KEY
);
INSERT INTO tmp_order_ids VALUES (201), (202);
ROLLBACK;

DROP TEMPORARY TABLE IF EXISTS tmp_order_ids;

应用层可以把清理放在连接归还前的 finally 路径中。若使用同一连接执行多个任务，建议给临时表加上任务语义明确的名字，并在任务成功、失败、超时三条路径都执行 DROP TEMPORARY TABLE IF EXISTS。

连接池的验收结果应明确写成：请求 A 执行 ROLLBACK 后，临时表仍在；执行删除动作后才是 DROP 后连接干净。

哪些操作会改变事务判断

CREATE TEMPORARY TABLE 和 DROP TEMPORARY TABLE 不会像普通建表那样触发隐式提交，但它们本身不能通过回滚撤销。例如在事务中创建临时表后执行 ROLLBACK，表仍会存在。

别把这条规则扩大到所有临时表操作。MySQL 8.4 文档列出，临时表上的 ALTER TABLE、CREATE INDEX 等操作会引起提交。需要事务原子性时，先完成表结构和索引准备，再开始真正的数据变更。

用一个最小检查表避免混淆

• 想撤销插入数据：使用 ROLLBACK，但不要期待表被删除。
• 想结束本次会话任务：使用 DROP TEMPORARY TABLE IF EXISTS。
• 想确认连接是否被复用：在连接池借出和归还日志中记录连接标识，别只记录事务编号。

连接断开后为什么看不到它了

客户端会话结束时，MySQL 会自动删除该会话创建的临时表。InnoDB 还会为会话临时表使用会话临时表空间，断开连接后相关空间会被截断并释放回池中。这个自动清理是兜底机制，不应替代应用在正常流程里的显式清理，因为连接池连接通常不会频繁断开。

生产排查可以记录三件事：临时表创建与删除是否成对、连接归还时是否仍存在临时表、同一物理连接是否承载了不同请求。这样能把“事务回滚了但数据还在”的现象定位到会话残留，而不是误判成 InnoDB 回滚失效。

常见问题

临时表会在 COMMIT 后自动消失吗？

不会。只要创建它的 MySQL 会话仍然存在，提交事务后仍可访问它。

连接池归还连接前只执行 ROLLBACK 可以吗？

不够。还要清理用户临时表，至少执行明确的 DROP TEMPORARY TABLE IF EXISTS，否则下一次借到同一连接的请求可能继承会话状态。

SHOW TABLES 能查到临时表吗？

不能依赖它。MySQL 文档说明 SHOW TABLES 不列出临时表，应用应使用直接查询或显式生命周期管理。

把生命周期写进连接使用约定

临时表适合在一个连接内完成中间结果计算，但它不是事务级变量。代码评审时同时检查创建、填充、消费、删除四个动作；遇到连接池，还要确认异常路径和超时路径一样会执行删除。记住这条边界，很多“回滚后临时数据还在”的问题就不会等到线上才暴露。