MySQL 临时表为什么突然消失：会话范围、连接池复用与断线验收

有一类 MySQL 报错很容易让人误判：刚刚创建成功的临时表，下一次查询却变成了 Table doesn't exist。如果这段 SQL 放在连接池管理的服务里，问题往往不在 CREATE TEMPORARY TABLE，而在“创建”和“查询”是不是落在同一个数据库会话。

临时表的名字可以相同，但它只属于创建它的连接。要稳定解决这类问题，先核对连接身份，再决定是把两步 SQL 放进同一借用周期，还是改成显式任务表。

先复现：为什么同名临时表在另一个连接里不存在

打开两个 MySQL 客户端，分别记作连接 A 和连接 B。在连接 A 中创建临时表并写入一行数据：

CREATE TEMPORARY TABLE tmp_order_ids (
    order_id BIGINT PRIMARY KEY
);

INSERT INTO tmp_order_ids (order_id) VALUES (10001);
SELECT CONNECTION_ID() AS session_id, * FROM tmp_order_ids;

连接 A 可以正常读到 10001。这时切到连接 B，执行：

SELECT CONNECTION_ID() AS session_id, * FROM tmp_order_ids;

通常会得到表不存在的错误。这里的关键不是两个客户端使用了同一个账号，而是 CONNECTION_ID() 不同。临时表的名字只在当前会话的名字空间内解析，账号权限并不会把它变成共享表。

连接池把哪一步拆开了

应用代码常见的写法是：先借一条连接创建临时表，方法返回时归还；下一段逻辑再从连接池借一条连接查询。即使连接池碰巧归还了同一条连接，这种写法也没有可靠保证，超时、并发请求或池内空闲连接顺序都可能让第二步落到连接 B。

可以把每次借用都打印出会话号，快速确认问题：

SELECT CONNECTION_ID() AS session_id,
       @@autocommit AS autocommit_mode,
       DATABASE() AS current_database;

如果创建和查询日志里的 session_id 不一致，临时表消失就已经解释清楚了。不要只记录业务请求 ID；请求 ID 相同并不代表底层数据库会话相同。

正确做法：把生命周期收进一次连接借用

临时表适合短链路中间结果，例如先筛出一批订单号，再和明细表关联。创建、填充、查询和清理应该都发生在同一次连接借用期间：

CREATE TEMPORARY TABLE tmp_order_ids (
    order_id BIGINT PRIMARY KEY
);

INSERT INTO tmp_order_ids (order_id)
SELECT order_id
FROM order_candidates
WHERE batch_id = 20260823;

SELECT d.order_id, d.amount
FROM order_detail AS d
JOIN tmp_order_ids AS t ON t.order_id = d.order_id;

DROP TEMPORARY TABLE IF EXISTS tmp_order_ids;

应用层要保证这几条 SQL 使用同一个连接对象，并在异常路径也归还连接。显式 DROP TEMPORARY TABLE 不是为了跨连接保留数据，而是让连接回池前的状态更容易观察；连接最终断开时，MySQL 仍会自动清理属于该会话的临时表。

同名重建会发生什么

在同一个会话里再次创建相同名字的临时表，旧临时表会被删除后重建。它不会更新另一个连接里的同名普通表，也不会让临时表覆盖其他会话的临时表。这个行为适合一次性批处理，但不适合把临时表当成跨请求缓存。

什么时候该放弃临时表

如果中间结果需要跨多个请求、跨多个连接，或者要被后台任务重试，就应该改用带任务标识的普通表，例如 order_batch_items。普通表可以用 task_id、状态字段和过期时间管理生命周期，代价是需要处理并发清理、索引和历史数据。

上线前用四个动作验收会话边界

1. 在创建和查询两处都记录 CONNECTION_ID()，确认两者一致。
2. 让一次请求中途抛出异常，确认连接回池前已执行清理或连接被正确重置。
3. 模拟连接断开后重新借用，确认旧临时表不可见，避免错误地依赖残留状态。
4. 并发运行两次不同任务，确认一个任务的临时表不会读到另一个任务的数据。

验收时别只看“查询成功”。还要把临时表中的行数、会话号和业务任务号放在同一条日志里，才能区分空结果、连接切换和数据筛选条件错误。

常见问题

临时表会不会被同名普通表覆盖？

在创建临时表的当前会话中，未带特殊限定时会优先解析临时表；其他会话仍然看到普通表。为了减少误解，临时表建议使用明显的 tmp_ 前缀。

事务回滚会删除临时表吗？

事务回滚主要影响事务中的数据变更，不应把它当成临时表生命周期控制。需要清理时显式删除，连接断开时由 MySQL 自动清理。

连接池能不能固定一条连接给一个用户？

不建议为了临时表长期占用连接。若业务确实需要跨步骤复用会话，应把整个流程封装在一次连接借用中，并设置超时、异常归还和并发上限。

临时表适合存放大批量数据吗？

要看中间结果规模和磁盘临时空间。大批量场景应观察内存、磁盘临时表、锁等待和清理时间；如果需要断点续跑，通常普通任务表更稳。

把“突然消失”改成可验证的连接问题

MySQL 临时表没有神秘的跨请求状态：创建它的会话结束，表就结束；连接池把两步操作拆到不同会话，查询自然会失败。把临时表操作收进一次连接借用，并在日志里记录 CONNECTION_ID()，通常就能把偶发报错变成一条清晰的验收链路。