MySQL存储过程频繁生成磁盘临时表，本质是其执行的SQL触发落盘，需从SQL写法优化（如避免跨表GROUP BY、含TEXT聚合、无索引ORDER BY）和参数配置（同步设置tmp_table_size与max_heap_table_size，不超过innodb_buffer_pool_size的25%～30%）双线入手，结合EXPLAIN检查Using temporary及监控Created_tmp_disk_tables占比（超15%须改SQL）。
MySQL 存储过程中频繁生成磁盘临时表（Created_tmp_disk_tables 持续上涨），本质不是“存储过程本身的问题”，而是它执行的 SQL 触发了临时表落盘——优化方向必须落在「SQL 写法 + 临时表参数配置」双线上，单调大 tmp_table_size 可能掩盖真实瓶颈，甚至引发内存争用。
查清是不是存储过程真在造磁盘临时表
别一上来就改配置。先确认问题是否出在存储过程内部：
- 执行
SHOW STATUS LIKE 'Created_tmp%';，重点看Created_tmp_disk_tables在你调用该存储过程前后是否明显增长 - 在存储过程中关键 SQL 前后加
SELECT @@tmp_table_size, @@max_heap_table_size;，确认会话级参数没被意外覆盖 - 对存储过程里每条核心 SELECT/JOIN/GROUP BY 语句单独
EXPLAIN，检查是否带Using temporary或Using filesort - 注意：如果语句含
BLOB/TEXT字段、或用了UNION、DISTINCT、跨 JOIN 的GROUP BY，MySQL 强制走磁盘临时表，跟内存大小无关
tmp_table_size 和 max_heap_table_size 怎么设才安全
这两个值决定“多大临时表能留在内存里”，但设太高反而危险：
- 它们取较小值生效，所以必须同步设置，例如都设为
256M：SET GLOBAL tmp_table_size = 268435456;和SET GLOBAL max_heap_table_size = 268435456; - 绝对不能超过
innodb_buffer_pool_size的 25%～30%，否则可能挤占缓冲池，导致整体性能雪崩 - 会话级修改（
SET SESSION）只影响当前连接，适合调试；全局修改需重启或确认已持久化到配置文件（如my.cnf中的[mysqld]段） - MySQL 8.0+ 默认
internal_tmp_mem_storage_engine = TempTable，比旧版MEMORY更省内存、支持变长行，不建议切回
存储过程里怎么写 SQL 才少造临时表
很多临时表是 SQL 写法“逼出来”的，尤其在循环或嵌套逻辑中：
- 避免在存储过程循环体里反复执行相同查询——把结果存进变量或小临时表（加索引！），而不是每次
SELECT ... INTO - 用
INSERT ... SELECT替代游标逐行处理，例如批量更新用户状态时，不要开游标读一行 update 一行 - GROUP BY 字段必须全部来自同一张表，且有联合索引覆盖（WHERE + GROUP BY 字段顺序一致），否则必走临时表
- 子查询尽量转为 JOIN，特别是
SELECT * FROM t1 WHERE id IN (SELECT id FROM t2)这类，容易触发物化子查询并落盘
innodb_tmpdir 能不能指向 SSD 提升性能
可以，但仅对 MySQL 8.0+ 的 InnoDB 内部临时表有效（比如大排序、大 GROUP BY 的中间结果），不影响用户显式创建的 CREATE TEMPORARY TABLE：
- 确认版本：
SELECT VERSION();必须 ≥ 8.0 - 设置路径前确保目录存在、MySQL 进程有读写权限、且不在系统盘（如
/ssd/mysql_tmp） - 配置项是
innodb_tmpdir = /ssd/mysql_tmp，不是tmpdir（后者管的是 general log、slow log 等） - 这个目录不会自动清理，需配合监控
SHOW GLOBAL STATUS LIKE 'Innodb_temp_table_info';和磁盘空间告警
真正难处理的不是参数数字，而是那些隐式触发磁盘临时表的 SQL 模式——比如跨表 GROUP BY、含 TEXT 的聚合、没索引的 ORDER BY。这些在 EXPLAIN 里一眼就能看到 Using temporary，但很多人直接调大内存参数绕过，结果上线后 buffer pool 告急，慢查询翻倍。盯住 Created_tmp_disk_tables / Created_tmp_tables 比值，持续高于 15% 就得动手改 SQL，而不是继续加内存。
