临时表空间是否被存储过程撑爆需分三步确认：先用df -h和ls -lh /var/lib/mysql/ibtmp1查磁盘及文件大小；再通过performance_schema定位高内存消耗的call线程；最后用explain分析存储过程内sql是否含using temporary或using filesort。
查清临时表空间是否真的被存储过程撑爆
存储过程本身不直接占用磁盘，但执行时可能生成大量临时表、排序结果或中间结果集，最终写入 ibtmp1（InnoDB 临时表空间）或 /tmp（系统临时目录）。先确认是不是它在吃空间：
运行 df -h 看磁盘使用率，再用 ls -lh /var/lib/mysql/ibtmp1 查看临时表空间文件大小；如果超过几十 GB，且 SHOW VARIABLES LIKE 'innodb_temp_data_file_path'; 返回的是类似 ibtmp1:12M:autoextend（无 :max: 限制），那基本就是它了。
定位哪个存储过程在疯狂创建临时表
不能靠猜，得抓实时行为。存储过程调用后会派生线程，关键线索藏在 performance_schema 里：
执行以下查询，找出最近活跃、且内存/临时表消耗高的线程：
SELECT t.THREAD_ID, p.PROCESSLIST_USER, p.PROCESSLIST_DB, p.PROCESSLIST_INFO,
m.CURRENT_NUMBER_OF_BYTES_USED AS mem_used_bytes
FROM performance_schema.threads t
JOIN performance_schema.processlist p ON t.THREAD_ID = p.THREAD_ID
JOIN performance_schema.memory_summary_by_thread_by_event_name m
ON t.THREAD_ID = m.THREAD_ID
WHERE p.PROCESSLIST_INFO LIKE '%CALL %'
AND m.EVENT_NAME LIKE 'memory/temptable/%'
ORDER BY mem_used_bytes DESC
LIMIT 5;
重点关注 PROCESSLIST_INFO 字段是否包含 CALL your_procedure_name，同时 mem_used_bytes 很高（比如 >100MB）；再结合 SHOW FULL PROCESSLIST 看对应线程的 State 是否为 Creating sort index、Copying to tmp table 或 Writing to net —— 这些都是临时数据落盘的典型信号。
检查存储过程内部是否触发隐式临时表
很多存储过程看似简单，但几行 SQL 就能引爆临时空间。常见雷区包括：
-
GROUP BY或ORDER BY字段没索引，且结果集大 → 触发Using temporary - 多表
JOIN缺少关联条件或索引 → 导致笛卡尔积，临时表爆炸 - 子查询返回大量行，又在外层做聚合 → 中间结果全进
ibtmp1 - 使用了
UNION（非UNION ALL）→ 去重必须建临时表 - 存储过程中循环调用
INSERT ... SELECT，且目标表无主键/索引 → 每次都重建临时结构
对可疑存储过程，用 EXPLAIN FORMAT=TRADITIONAL 执行其核心查询语句（不是 CALL，是把里面 SQL 拿出来单独 EXPLAIN），重点看 Extra 列是否含 Using temporary 或 Using filesort。
临时空间已爆满时的应急与长期控制
如果 ibtmp1 已涨到几百 GB，且服务卡死：
- 立即杀掉对应会话：
KILL [THREAD_ID];（注意：这只是中断执行，已分配的临时空间不会立刻释放） - 重启 MySQL 是唯一能彻底清空
ibtmp1的方式（官方明确说明：正常关闭时该文件会被删除并重建） - 重启前务必修改配置，加硬限制：
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2G（根据实例规格设合理上限） - 长期规避：禁用存储过程中不必要的
ORDER BY、强制小批量处理循环、给JOIN和GROUP BY字段补索引、避免在存储过程里做跨库大表关联
真正难缠的不是单个存储过程，而是它嵌套调用、循环生成临时结果的链路——这类问题必须结合 performance_schema.events_statements_history_long 回溯完整执行栈，否则永远在治标。
