必须显式 DROP TEMPORARY TABLE IF EXISTS，否则连接池复用下第二次执行报错；MySQL 不支持 CREATE TEMPORARY TABLE IF NOT EXISTS，因语法层面 TEMPORARY 与 IF NOT EXISTS 不兼容，解析阶段即报错。
必须显式 DROP TEMPORARY TABLE IF EXISTS，否则连接池复用下第二次执行直接报错；不能用 CREATE TEMPORARY TABLE IF NOT EXISTS——MySQL 语法不支持，会抛 ERROR 1305 (42000)。
为什么 CREATE TEMPORARY TABLE IF NOT EXISTS 会报错
MySQL 在语法解析阶段就拒绝该写法，根本原因是 TEMPORARY 和 IF NOT EXISTS 不兼容。你写 CREATE TEMPORARY TABLE IF NOT EXISTS tmp，服务器直接报 FUNCTION db_name.tmp does not exist，这不是权限或表名问题，是语法规则硬限制。
正确做法只有两种：
- 先
DROP TEMPORARY TABLE IF EXISTS tmp，再CREATE TEMPORARY TABLE tmp (...) - 建表后用
TRUNCATE TABLE tmp清空数据，避免重复 DDL 开销（适合结构固定、仅数据变化的场景）
怎么安全填充临时表：别用游标，优先 INSERT INTO ... SELECT
游标循环插入在 MySQL 中是典型性能陷阱：每次 INSERT 都触发日志写入、锁管理、语句解析，5 万行数据实测比批量插入慢 30 倍以上。
应直接用单条语句完成数据加载：
-
INSERT INTO tmp_calc SELECT id, SUM(val) FROM t GROUP BY id—— 简洁、原子、可优化 - 若源查询含
NULL而目标字段定义为NOT NULL，需提前COALESCE(val, 0)或调整字段定义 - 避免在
SELECT子句中调用复杂函数或子查询，否则优化器可能误估行数，触发磁盘临时表（Created_tmp_disk_tables计数上升）
字段类型和引擎选错，会让临时表“悄悄变慢”
临时表不是建完就完事，字段和引擎选择直接影响是否走内存还是掉磁盘：
- 含
TEXT或BLOB字段 → 强制退化为磁盘 MyISAM 表，速度断崖下跌 - 显式写
ENGINE=MEMORY并不总更快：一旦超tmp_table_size或max_heap_table_size中较小值，仍会无声降级为磁盘表 - MySQL 8.0+ 默认用
INNODB作临时表引擎（由internal_tmp_mem_storage_engine=INNODB控制），对大结果集更稳；小数据量且确定不超内存时，ENGINE=MEMORY可省去事务开销 - 字段长度要严丝合缝：用
VARCHAR(32)代替VARCHAR(255)，TINYINT代替INT，减少隐式转换和内存放大
动态 SQL 里引用不到临时表，这是硬限制
临时表在存储过程里建好后，静态 SQL（如 SELECT * FROM tmp）能正常访问；但一旦进 PREPARE/EXECUTE 流程，就彻底不可见：
-
SET @sql = 'SELECT * FROM tmp'; PREPARE stmt FROM @sql; EXECUTE stmt;→ 报Table 'tmp' doesn't exist - 这不是配置或权限问题，是 MySQL 解析作用域隔离导致的硬限制
- 绕不过去：要么把逻辑全写成静态 SQL，要么改用 CTE（MySQL 8.0+）替代简单中间结果场景
临时表生命周期只绑定会话，不依赖事务，也不跨连接；但连接池让“自动销毁”失效——真正容易被忽略的，是那个看似冗余的 DROP TEMPORARY TABLE IF EXISTS，它不是防御性编程，而是生产环境的刚需。
