MySQL中CREATE TEMPORARY TABLE不支持IF NOT EXISTS语法，正确做法是先DROP TEMPORARY TABLE IF EXISTS再CREATE，或首次CREATE后复用时TRUNCATE；INSERT INTO...SELECT远快于游标循环；默认InnoDB临时表更稳，无需显式指定ENGINE=MEMORY；字段类型应精准设计以提升性能。
CREATE TEMPORARY TABLE 不能加 IF NOT EXISTS
MySQL 存储过程里写 CREATE TEMPORARY TABLE IF NOT EXISTS tmp_table 会直接报错：ERROR 1305 (42000): FUNCTION db_name.tmp_table does not exist。这不是权限或表名问题，是语法解析阶段就拒绝——IF NOT EXISTS 在临时表创建语句中根本不被支持。
正确做法只有两种：
- 每次先
DROP TEMPORARY TABLE IF EXISTS tmp_table，再CREATE TEMPORARY TABLE tmp_table - 或跳过
DROP，直接CREATE TEMPORARY TABLE tmp_table（前提是确保上一次调用已结束、会话已断；但连接池场景下会话复用，必须显式清理）
别信“自动覆盖”这种说法：同一会话中重复执行 CREATE TEMPORARY TABLE tmp_table 会报 ERROR 1050 (42S01): Table 'tmp_table' already exists。
INSERT INTO ... SELECT 比游标循环快 30 倍以上
临时表填充时，用 INSERT INTO tmp_table SELECT ... 是唯一合理选择；用游标 + INSERT VALUES 循环是典型性能陷阱。
原因很实在：
- 每次循环都要走一遍语句解析、权限检查、redo 日志写入（哪怕关了 binlog）
- 而批量插入只触发一次解析和一次 I/O 批量提交
- 实测 5 万行数据：批量插入约 120ms；等价的
WHILE循环插入超 3.8s
注意两个易错点：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 源查询若含
ORDER BY RAND()或复杂子查询，优化器可能低估结果集大小，导致内存不足、被迫落盘（Created_tmp_disk_tables计数上升） - 目标字段定义为
NOT NULL，但源数据有NULL，语句直接失败，得提前用COALESCE(col, default_val)处理
别手动指定 ENGINE=MEMORY，除非你真懂 tmp_table_size
MySQL 8.0+ 默认内部临时表引擎已是 InnoDB（由 internal_tmp_mem_storage_engine=INNODB 控制），不是 MEMORY。显式写 ENGINE=MEMORY 看似“更快”，实际风险更大：
- 一旦数据量超过
tmp_table_size和max_heap_table_size中较小的那个值，MySQL 会无声降级为磁盘表（MyISAM 引擎），反而更慢 - 而默认的 InnoDB 临时表对大结果集更稳，支持事务一致性，且能利用 buffer pool 缓存
所以，除非你确认数据永远 ≤ 1MB 且字段全是固定长度，否则直接省略 ENGINE 子句，让 MySQL 自己决定。
TRUNCATE 而非 DROP 是同一会话内重用的正解
在连接池环境下，同一个数据库连接会被反复复用。如果存储过程每次都要 DROP 再 CREATE，会产生额外解析开销和元数据锁竞争——并发一高，CREATE TEMPORARY TABLE 就成瓶颈。
推荐模式是：
- 首次调用前：用
CREATE TEMPORARY TABLE tmp_table建表（不带IF NOT EXISTS） - 后续调用：直接
TRUNCATE TABLE tmp_table清空数据，再INSERT SELECT - 避免在存储过程末尾写
DROP——没意义，会话断开时自动销毁；还可能干扰连接池的连接复用逻辑
真正容易被忽略的是字段类型设计：用 TINYINT 代替 INT，VARCHAR(32) 代替 VARCHAR(255)，不只是省空间，还能减少隐式转换、避免临时表分配内存翻倍。
