存储过程本身不占磁盘空间，真正触发磁盘临时表的是其内部执行的SQL语句；需通过SHOW GLOBAL STATUS检查Created_tmp_disk_tables跳涨、用EXPLAIN确认Using temporary（尤其on disk）、同步设置tmp_table_size与max_heap_table_size（如均设64MB且不超过innodb_buffer_pool_size的25%～30%）、避免循环建临时表，并清理膨胀的ibtmp1。
存储过程里哪条SQL在往磁盘写临时表
不是存储过程本身占空间，而是它执行的某条 SELECT、GROUP BY 或 ORDER BY 触发了落盘。关键看两点：
- 执行
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';，调用前后数值是否跳涨 - 对存储过程中每条核心查询单独跑
EXPLAIN，重点盯Extra列是否含Using temporary—— 如果还带on disk或Copying to tmp table on disk，就是它 - 特别注意：含
TEXT/BLOB字段、UNION、跨表GROUP BY、或DISTINCT配合大字段的语句，MySQL 强制走磁盘临时表，调大tmp_table_size也无效
tmp_table_size 和 max_heap_table_size 没配平
这两个值取较小者生效，但很多人只改 tmp_table_size，结果实际阈值还是默认 16MB（MySQL 5.7）或更低。后果是：所有稍大的中间结果全落盘到 ibtmp1 或系统 /tmp，而这两个位置通常没设上限。
- 必须同步设置：例如都设为
67108864（64MB），命令为SET GLOBAL tmp_table_size = 67108864;和SET GLOBAL max_heap_table_size = 67108864; - 不能超过
innodb_buffer_pool_size的 25%～30%，否则会挤占缓冲池，引发雪崩 - 修改后需
SET PERSIST（5.7.20+）或写入my.cnf并重启才持久化；仅SET GLOBAL重启即失效
存储过程内循环反复建临时表
常见低效模式：在 WHILE 循环里不断 CREATE TEMPORARY TABLE → INSERT INTO ... SELECT → DROP TABLE。每次创建都会申请新内存/磁盘空间，连接不关闭，这些空间不会释放。
- 改成一次性建表 + 批量插入，例如用
INSERT INTO temp_table SELECT ... FROM big_table WHERE ...替代逐行游标处理 - 如果必须循环，把中间结果存进变量或带索引的常规表（
CREATE TABLE而非TEMPORARY），避免反复分配 - 检查
performance_schema.memory_summary_global_by_event_name中memory/temptable/physical_ram是否异常高，确认是不是temptable引擎吃掉了物理内存
ibtmp1 已暴涨但无法在线收缩
ibtmp1 是 InnoDB 临时表空间文件，一旦涨到几十 GB，光改配置没用——它不会自动变小。这是最常被忽略的硬伤。
- 唯一可靠清理方式：先执行
SET GLOBAL innodb_fast_shutdown = 0;，再完整重启 MySQL 实例，启动时会重建ibtmp1为初始大小（默认 12MB） - 重启前必须确认：无长事务（查
INNODB_TRX）、主从延迟为 0、无运行中 DDL - 若无法重启，可临时加限：在
my.cnf中设innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:5G，防止继续膨胀
ibtmp1 堆着。查清哪条 SQL 在刷盘，配平两个 size 参数，再砍掉循环建表，最后处理 ibtmp1，四步缺一不可。 
