MySQL存储过程中CREATE TEMPORARY TABLE不支持IF NOT EXISTS，会因语法解析错误直接报ERROR 1305；正确做法是先DROP TEMPORARY TABLE IF EXISTS或TRUNCATE，再CREATE，且应优先使用INSERT SELECT批量填充而非游标循环。
CREATE TEMPORARY TABLE 不能加 IF NOT EXISTS
MySQL 存储过程中执行 CREATE TEMPORARY TABLE IF NOT EXISTS 会直接报错 ERROR 1305 (42000): FUNCTION db_name.temp_table does not exist，不是逻辑错误，是语法解析阶段就拒绝。根本原因在于 MySQL 把 IF NOT EXISTS 当作函数调用去解析了——它试图找一个叫 temp_table 的函数，而不是做建表条件判断。
正确做法只有两种：
- 先用
DROP TEMPORARY TABLE IF EXISTS temp_name清理（注意：这里IF EXISTS是合法的） - 或者确保每次调用前该临时表一定不存在，靠会话隔离性自然规避（比如存储过程只在新连接中执行）
别指望“加个 IF NOT EXISTS 就能防重”，它在这里就是语法禁区。
同一会话内重复执行要显式清空，不是靠 DROP
临时表生命周期绑定会话，但**同一会话多次调用同一个存储过程时，上一次创建的临时表不会自动消失**——它还挂着，再执行 CREATE TEMPORARY TABLE temp_name 就会报 Table 'temp_name' already exists。
所以推荐组合操作：
-
DROP TEMPORARY TABLE IF EXISTS temp_name—— 安全兜底，避免建表失败 - 或改用
TRUNCATE TABLE temp_name—— 如果表结构不变、只需清数据，比 DROP + CREATE 更轻量 - 建表后立刻
INSERT INTO temp_name SELECT ...填充，不要留空表占内存
特别注意：TRUNCATE 不释放表定义，但重置 auto_increment 和清除所有行；DROP 则连定义一起扔掉，下次得重建。
INSERT INTO ... SELECT 比循环 INSERT 快 30 倍以上
在存储过程中往临时表塞数据，用游标 + INSERT VALUES 循环是典型性能黑洞。实测 5 万行数据，等价逻辑下：
-
INSERT INTO temp SELECT ...耗时约120ms - WHILE 循环逐条
INSERT耗时常超3.8s
慢的根本原因是每次循环都触发完整语句生命周期：解析、权限检查、redo 日志写入（哪怕 binlog 关了，InnoDB 还得记）、锁管理开销。而批量插入只走一次解析和一次 I/O 批处理。
但要注意两个坑：
- 源查询若含
COUNT(*) OVER()或复杂子查询，优化器可能低估结果集大小，导致内存临时表溢出到磁盘（Created_tmp_disk_tables上升） - 目标字段定义为
NOT NULL，但源数据有NULL，语句直接失败——得提前用COALESCE(col, default_val)处理
别硬切 ENGINE=MEMORY，InnoDB 临时表更稳
MySQL 8.0+ 默认临时表引擎已是 InnoDB（由系统变量 internal_tmp_mem_storage_engine=INNODB 控制），不是 MEMORY。显式写 ENGINE=MEMORY 反而容易翻车：
- 一旦数据超过
tmp_table_size和max_heap_table_size中较小值（默认通常 64MB），MySQL 会无声降级为磁盘 MyISAM 表，I/O 暴增 - InnoDB 临时表支持事务一致性、行锁、崩溃恢复，对大中间结果更可靠
- 小数据量（JOIN 或
WHERE，记得给关键字段加INDEX
真正该调的不是引擎，而是 tmp_table_size 和 max_heap_table_size —— 它们共同决定内存临时表上限。如果确定中间结果稳定小于 64MB，才考虑调高这两个值，而不是换引擎。
最常被忽略的一点：临时表字段类型越紧凑越好。用 TINYINT 代替 INT，VARCHAR(32) 代替 VARCHAR(255)，不只是省空间，还能减少隐式转换、避免临时表因字段膨胀意外溢出。
