临时表不是省内存的工具，而是将内存压力显式化、可管理化的手段；它不降低内存占用，反而通过可控的结构定义、批量插入和及时清理，使内存使用变得可观察、可优化。
临时表本身不“降低”内存占用，而是帮你控制它
直接说结论：临时表不是省内存的工具，它是把内存压力显式化、可管理化的手段。MySQL 8.0+ 默认用 InnoDB 做临时表引擎（由 internal_tmp_mem_storage_engine=INNODB 控制），它会动态在内存和磁盘间平衡；而手动建 ENGINE=MEMORY 的临时表，一旦超 tmp_table_size 或 max_heap_table_size 中较小值，就静默降级为磁盘表——反而更慢、更占 I/O。
建表前必须设字段精度，别留“宽字段”吃内存
常见错误是复制源表结构时照搬 VARCHAR(255) 或 TEXT，但临时表只存中间结果，字段越宽，每行内存开销越大，还容易触发隐式转换导致全字段拷贝。
- 用
TINYINT代替INT存状态码（如 0/1/2） - 用
VARCHAR(32)代替VARCHAR(255)存短标识（如订单号前缀、渠道码） - 明确允许
NULL的字段要加NULL，否则 MySQL 可能额外分配空值处理空间 - 避免在临时表里放
BLOB、TEXT—— 它们默认走磁盘，且不计入tmp_table_size限制
INSERT 必须批量，禁用循环逐行插入
存储过程中用 WHILE 或游标往临时表插 1 万行，比 INSERT INTO temp SELECT ... 慢 30 倍以上。根本原因不是“语法慢”，是每次循环都触发一次语句解析、权限检查、redo 日志写入（哪怕关了 binlog）。
- 优先用
INSERT INTO temp_table SELECT ...一次性填充 - 若源数据含
NULL而目标字段定义为NOT NULL，提前用COALESCE(col, default_val)处理，否则语句直接报错中断 - 如果
SELECT里有复杂子查询或函数，优化器可能低估行数，导致内存预分配不足，触发Created_tmp_disk_tables计数上升——这时得加SQL_BUFFER_RESULT强制物化中间结果
用完立刻清空，别依赖“自动销毁”
临时表生命周期绑定会话，但同一会话中反复调用同一存储过程时，上一轮的临时表还在，再 CREATE TEMPORARY TABLE 就会报错 ERROR 1050 (42S01): Table 'xxx' already exists。很多人误以为“会话断就清”，却忘了存储过程常驻连接池场景。
- 建表前加
DROP TEMPORARY TABLE IF EXISTS temp_xxx（注意：MySQL 不支持CREATE TEMPORARY TABLE IF NOT EXISTS，但DROP支持） - 或者建完立刻
TRUNCATE temp_xxx，比DROP+CREATE开销小，也避免重定义结构 - 别在存储过程末尾留着
DROP—— 如果过程异常退出，DROP不执行，下一次调用就卡住
真正影响内存占用的，从来不是“有没有临时表”，而是你给它划了多少行、多宽的字段、怎么填进去、填完怎么用。临时表只是把模糊的内存压力，变成你能看见、能调、能测的一张表。
