MySQL临时表生命周期绑定连接而非存储过程，会话结束才销毁；连接复用时需显式DROP或TRUNCATE避免冲突，且CREATE TEMPORARY TABLE不支持IF NOT EXISTS语法。
临时表生命周期绑定的是 connection，不是 stored procedure
存储过程执行完不会销毁临时表，真正决定销毁时机的是客户端连接（connection）是否断开。MySQL 为每个连接维护独立的临时表命名空间，CREATE TEMPORARY TABLE 创建的表被注册到该连接的上下文中，只要连接还活着（哪怕存储过程已返回），表就一直存在。
常见误解是“存储过程结束 = 临时表消失”，实际场景中：PHP 脚本调用一次存储过程，过程中建了 tmp_user，脚本没 close() 连接，下一次请求复用同一连接，CREATE TEMPORARY TABLE tmp_user 就会报错 Table 'tmp_user' already exists。
- 存储过程内建的临时表，调用结束后仍存活，直到连接关闭
- 连接池环境下尤其危险：连接被复用，上一个请求残留的临时表可能干扰后续逻辑
- 若想每次调用都干净重建，必须显式加
IF NOT EXISTS或先DROP TEMPORARY TABLE
为什么 DROP TEMPORARY TABLE 在存储过程中经常要配 TRUNCATE
临时表支持主键、唯一索引等约束，但 CREATE TEMPORARY TABLE IF NOT EXISTS 不校验结构一致性——如果表已存在且字段定义不同，后续 INSERT 可能因类型不匹配或约束冲突失败。
更典型的问题是重复插入相同主键值：比如存储过程循环调用，每次都往同名临时表插数据，不清理就会触发 Duplicate entry 错误。
-
TRUNCATE TABLE tmp_xxx比DELETE FROM tmp_xxx更快，且重置自增计数器 -
TRUNCATE不能在事务中回滚（对 MyISAM 和 InnoDB 的 MEMORY 表都生效） - 务必放在
CREATE TEMPORARY TABLE IF NOT EXISTS之后、首次INSERT之前
SHOW TABLES 看不到临时表，但 INFORMATION_SCHEMA.TABLES 能查到？
SHOW TABLES 默认只显示当前数据库下的普通表，它根本不会扫描临时表命名空间——这是设计使然，不是 bug。
但如果你真需要确认某临时表是否存在（比如调试时），可以用：
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = '' AND TABLE_NAME = 'tmp_user';
注意：TABLE_SCHEMA 为空字符串才表示临时表；普通表这里显示的是数据库名。
- 这个查询结果仅对当前连接有效，其他连接查不到你的临时表
- 不要依赖
INFORMATION_SCHEMA做业务判断，它有性能开销，且结果可能滞后 - 最可靠的方式仍是捕获
CREATE TEMPORARY TABLE的 SQLSTATE 错误码
连接异常中断时，临时表真的会被清理吗？
MySQL 服务端在检测到连接断开（如客户端崩溃、网络闪断、超时 kill）时，会触发 close_thread_table_cache() 清理函数，保证所有该连接持有的临时表被立即释放。
但有两个例外场景容易漏掉：
- 使用长连接 + keepalive 的应用，TCP 连接未真正断开，MySQL 无法感知，临时表持续占用内存
- 某些中间件（如 ProxySQL）或云数据库代理层，可能缓存连接状态，导致 MySQL 实际未收到 disconnect 信号
所以生产环境别完全依赖自动销毁——关键路径上建议显式 DROP TEMPORARY TABLE，尤其是涉及大容量中间结果时。
