mysql存储过程中create temporary table后select报错“table doesn't exist”，根本原因并非建表失败，而是mysql禁止在子查询、视图或函数中引用临时表，且连接池复用会导致残留、事务锁竞争可能阻塞insert，临时表本身也不出现在show tables中。
为什么存储过程里CREATE TEMPORARY TABLE后SELECT报错“Table doesn’t exist”
不是表没建成功，而是你用了子查询、CTE或视图引用方式——MySQL明确禁止在SELECT子查询、VIEW定义、或函数体中直接引用当前会话的临时表。比如SELECT * FROM (SELECT * FROM tmp_user) t必然失败，哪怕tmp_user刚用CREATE TEMPORARY TABLE建好。
常见错误现象：
-
ERROR 1146 (42S02): Table 'dbname.tmp_user' doesn't exist（注意：错误里带数据库名，说明MySQL误解析成普通表） - 存储过程执行到
SELECT ... FROM tmp_user就中断，但SHOW FULL TABLES WHERE Table_type = 'TEMPORARY'能查到该表
根本原因：MySQL解析器在子查询上下文中不识别当前会话的临时表作用域。它只在顶层SELECT、INSERT、UPDATE等语句中生效。
实操建议：
- 把逻辑拆成两步：先
CREATE TEMPORARY TABLE tmp_user AS SELECT ...，再单独写SELECT * FROM tmp_user - 避免嵌套：不要写
SELECT * FROM (SELECT id FROM tmp_user) t，改用SELECT id FROM tmp_user - MySQL 8.0+ 可用
WITH替代简单场景，但WITH不能多次读写，也不支持INSERT/UPDATE
存储过程反复调用时出现“Table 'xxx' already exists”
连接池复用导致临时表残留——PHP PDO持久连接、Java HikariCP等场景下，会话未真正断开，上一次创建的tmp_user还在，下次调用又执行CREATE TEMPORARY TABLE tmp_user就会报错。
MySQL不支持CREATE TEMPORARY TABLE IF NOT EXISTS语法，所以不能靠IF NOT EXISTS兜底。
实操建议：
- 每次进存储过程第一行加
DROP TEMPORARY TABLE IF EXISTS tmp_user，再建新表 - 别用
TRUNCATE TABLE tmp_user代替DROP——如果表不存在，TRUNCATE会直接报错 - 显式命名临时表，避免用系统生成名（如
#sql-xxx），否则无法可靠DROP - 若性能敏感，可考虑
CREATE TEMPORARY TABLE tmp_user (...) ENGINE=MEMORY+TRUNCATE组合，但前提是确保表一定存在
为什么SHOW TABLES看不到刚建的临时表
这是正常行为，不是错误。SHOW TABLES只查information_schema.tables，而临时表根本不在这个视图里注册——它只对当前连接可见，且刻意“隐身”防止元数据膨胀。
常见误判：
- 执行
CREATE TEMPORARY TABLE tmp_log AS SELECT ...后跑SHOW TABLES LIKE 'tmp_log'返回空，以为建失败 - 用
SELECT * FROM information_schema.tables WHERE table_name = 'tmp_log'查不到，就去翻datadir找文件
正确验证方式：
- 直接
SELECT * FROM tmp_log——能查就是存在 - 运行
SHOW FULL TABLES WHERE Table_type = 'TEMPORARY'，这是唯一列出当前会话所有临时表的命令 - 需要看结构？用
SHOW CREATE TABLE tmp_log，别指望DESCRIBE或information_schema.columns
临时表查不到数据，但INSERT明明执行了
最可能原因是事务隔离级别和隐式提交干扰。临时表本身生命周期绑定会话，不依赖事务，但如果你在REPEATABLE READ下执行INSERT INTO tmp_log SELECT ... FROM real_table，而real_table被其他事务锁住，会导致INSERT卡住甚至超时，表面看是“插入了但查不到”，实际是插入根本没完成。
另一个隐蔽点：INSERT ... SELECT在某些旧版本MySQL中会触发源表的读锁（尤其没走索引时），阻塞自身后续对临时表的SELECT。
实操建议：
- 优先用
CREATE TEMPORARY TABLE tmp_log AS SELECT ...替代INSERT INTO ... SELECT，前者只建一致性读视图，不加锁 - 确认
SELECT子句里的条件字段有索引，避免全表扫描引发的意向锁扩散 - 检查
SELECT @@autocommit，如果为0（手动事务模式），确保INSERT后有COMMIT——虽然不影响临时表数据，但可能掩盖锁等待问题
临时表的“看不见”和“查不到”多数不是bug，而是设计使然；真正要盯紧的是连接池复用、子查询禁用、以及隐式锁竞争这三点——它们才是线上出问题的高频位置。
