MySQL临时表在存储过程中不能跨动态SQL语句复用，因PREPARE/EXECUTE在独立作用域解析而不可见；需显式DROP避免重复创建错误；优先用INSERT...SELECT批量操作替代游标循环；应显式定义字段类型并合理建索引。
临时表在存储过程中为什么不能跨语句复用
MySQL存储过程里建的CREATE TEMPORARY TABLE，作用域只到当前会话结束，但关键限制是：它**不能在PREPARE/EXECUTE动态SQL中直接引用**。不是语法报错，而是执行时提示Table 'xxx' doesn't exist——因为动态SQL在独立作用域解析，看不见上一步建好的临时表。
- 静态SQL（比如直接写
INSERT INTO tmp SELECT ...）能正常访问临时表 - 一旦用
SET @sql = 'SELECT * FROM tmp'; PREPARE stmt FROM @sql; EXECUTE stmt;，就失败 - 临时表名不能拼接进动态SQL字符串再执行，这是硬限制，不是权限或配置问题
用INSERT ... SELECT替代循环拼接更稳
很多人想把多步计算结果一行行INSERT进临时表，尤其习惯用游标+循环。但MySQL游标本身慢，加上每次INSERT都触发日志和锁开销，效率反而比单条批量操作低得多。
- 优先写成
INSERT INTO tmp_table SELECT ... FROM t1 JOIN t2 WHERE ... GROUP BY ... - 避免在循环里反复
INSERT INTO tmp_table VALUES (@a, @b) - 如果必须分批处理（比如数据量超内存），用
LIMIT+OFFSET或主键范围切分，而不是游标 - 注意
INSERT ... SELECT默认使用STATEMENT级别复制，在GTID模式下可能报错，需确认binlog_format为MIXED或ROW
DROP TEMPORARY TABLE IF EXISTS不是可有可无
存储过程可能被多次调用，而临时表不会自动清理（除非会话断开）。不显式DROP会导致第二次执行时报Table 'tmp' already exists，尤其在连接池场景下，同一个连接反复执行同一过程时极易踩坑。
- 在建表前加
DROP TEMPORARY TABLE IF EXISTS tmp_calc; - 不要依赖“过程退出自动删”，连接复用会让这个假设失效
- 如果临时表结构固定，也可以考虑用
TRUNCATE TABLE tmp_calc;代替重建，省去DDL开销 -
DROP TEMPORARY TABLE只对当前会话有效，不影响其他连接，安全
临时表字段类型要和实际数据严丝合缝
用SELECT ... INTO OUTFILE或CREATE TEMPORARY TABLE AS SELECT建表时，MySQL会按源字段推导类型，但容易出偏差：比如源字段是VARCHAR(255)但实际存了300字符，临时表就截断；或者DECIMAL精度丢失导致后续聚合不准。
- 显式定义结构：
CREATE TEMPORARY TABLE tmp_calc (id BIGINT, amt DECIMAL(18,2), dt DATE); - 避免
CREATE TEMPORARY TABLE tmp_calc AS SELECT ...用于生产逻辑 - 临时表加索引有意义：对后续
JOIN或WHERE字段建INDEX，特别是数据量超1万行后 - 注意
MEMORY引擎临时表不支持TEXT/BLOB，要用InnoDB引擎显式指定：ENGINE=InnoDB
临时表真正省时间的地方，从来不是“能存数据”，而是避开重复扫描、减少中间结果落盘、让优化器有明确统计信息可依——这些细节一松动，反而比不用还慢。
