存储过程建临时表爆内存是因为其大小受tmp_table_size和max_heap_table_size中较小值限制，超限即落盘，若tmpdir空间不足或权限受限则报“temporary table full”；必须同步调大两个参数并检查磁盘空间与写入权限。
存储过程里建临时表为什么会爆内存？
因为 CREATE TEMPORARY TABLE 默认走 MEMORY 引擎（MySQL 8.0 前）或 TempTable 引擎（8.0+），但它的大小仍受 tmp_table_size 和 max_heap_table_size 中较小值限制。哪怕你只在存储过程里插入 50 万行 INT，只要总大小超限，就会强制落盘——而落盘失败时，错误就显示为 Temporary table full。
常见诱因包括：
- 存储过程内循环插入大量数据，未分批提交，导致单次临时表膨胀
- 用
INSERT ... SELECT从大表导出中间结果，没加LIMIT或过滤条件 - 临时表字段含
VARCHAR(1024)或TEXT，实际分配远超预期内存 - 多个并发存储过程同时建临时表，共享同一内存池，互相挤占
为什么调了 tmp_table_size 还报错？
MySQL 实际取 tmp_table_size 和 max_heap_table_size 的较小值作为上限。比如你只设了 tmp_table_size = 512M，但 max_heap_table_size 还是默认的 16M，那临时表最多只能用 16MB —— 存储过程一写入几万行就触发落盘，接着可能因 tmpdir 权限/空间不足而报错。
必须同步设置且值相等：
- 会话级生效（仅当前存储过程连接）：
SET SESSION tmp_table_size = 268435456;+SET SESSION max_heap_table_size = 268435456; - 全局生效（需重启）：在
my.cnf的[mysqld]下写两行，都用256M（单位支持 M/G，不认 MB/GB） - 注意：
max_heap_table_size还约束所有显式MEMORY表，别设太高引发 OOM
怎么确认真是临时表撑爆，而不是磁盘写满？
先别改参数，跑三句诊断命令：
-
SELECT @@tmpdir;→ 拿到 MySQL 临时目录路径，再df -h /path/to/tmpdir看剩余空间 -
SHOW GLOBAL STATUS LIKE 'Created_tmp%';→ 若Created_tmp_disk_tables比Created_tmp_tables高很多，说明频繁落盘 - 查错误日志：
tail -20 $(mysql -Nse "SELECT @@log_error")→ 找No space left on device或Could not create temporary file
如果日志里有 write failed 且 df 显示 /tmp 或自定义 tmpdir 分区 95%+，那问题根子在磁盘，不是参数。
存储过程里处理大数据量的更稳做法
调参只是兜底，真要可靠，得从逻辑上规避大临时表：
- 用
INSERT INTO ... SELECT ... LIMIT 10000分批插入，配合WHILE循环和ROW_COUNT()判断 - 避免在临时表里存冗余字段；能用
INT别用BIGINT，VARCHAR(50)比VARCHAR(255)更省内存 - 确认
innodb_file_per_table = ON，否则临时表落盘可能写进共享表空间ibdata1，删不缩容 - 关键点：存储过程结束前显式
DROP TEMPORARY TABLE IF EXISTS xxx;，别依赖会话自动清理——长事务下可能卡住资源
最易被忽略的是：tmpdir 路径权限是否对 mysql 用户可写，以及 SELinux/AppArmor 是否拦截了写入。这两点不检查，调再大的参数也没用。
