应通过Created_tmp_disk_tables等状态变量判断临时表实际开销,若其与Created_tmp_tables比值超5%且Sort_merge_passes、Handler_read_rnd_next同步升高,表明大结果集、内存不足、缺索引三重问题;需协同调整tmp_table_size、sort_buffer_size、read_rnd_buffer_size等会话级参数。

查 Created_tmp_% 状态变量确认是否真在用临时表
光看 EXPLAIN 里的 Using temporary 不够——它只表示“可能用”,不代表实际开销大。真正反映运行时消耗的是状态变量。执行:SHOW GLOBAL STATUS LIKE 'Created_tmp_%';
重点关注三个值:
-
Created_tmp_disk_tables:在磁盘上创建的临时表数量,这个值高说明内存不够,已降级到磁盘,性能灾难信号 -
Created_tmp_tables:总临时表创建数(含内存和磁盘),用于判断频率 -
Created_tmp_files:内部使用的临时文件数,通常伴随disk_tables上升
如果 Created_tmp_disk_tables 持续增长,且与 Created_tmp_tables 的比值 > 5%,基本可以断定临时表正在拖慢查询。
结合 Sort_merge_passes 和 Handler_read_rnd_next 判断瓶颈类型
临时表常和排序、连接、去重耦合。单看 Created_tmp_% 只知“用了”,不知“为什么用”或“卡在哪”。需要交叉验证:
- 若
Sort_merge_passes同步升高 → 问题大概率出在ORDER BY或GROUP BY排序阶段,内存不足导致归并排序次数暴增 - 若
Handler_read_rnd_next显著增加 → 说明 MySQL 正在对临时表做随机读(比如对未索引的临时结果集反复查找),这是典型的低效访问模式 - 两者都高 +
Created_tmp_disk_tables高 → 基本锁定是“大结果集 + 内存配置过小 + 无合适索引”三重叠加
注意:Sort_merge_passes 每次归并至少涉及一次磁盘 IO,它的值每秒超过 1–2 就值得警惕。
用 SHOW PROFILE 定位具体阶段耗时
SHOW PROFILE 能把一条 SQL 拆成真实执行阶段,比 EXPLAIN 更贴近 runtime 行为。开启后执行目标 SQL:
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录,或需要将该能力封装成可公开复用的 Codex skill。
SET profiling = 1;<br>SELECT ... GROUP BY ...;<br>SHOW PROFILES;<br>SHOW PROFILE FOR QUERY N;
重点观察以下阶段:
-
Creating tmp table:建表本身耗时长 → 检查tmp_table_size和max_heap_table_size是否太小 -
Copying to tmp table on disk:明确提示已落盘 → 必须调大上述两个参数,或加索引减少中间结果集 -
Sorting result或Performing filesort:排序阶段占大头 → 优先优化ORDER BY/GROUP BY字段的索引覆盖
注意:SHOW PROFILE 默认只保留最近 15 条,生产环境慎用;且仅对当前会话有效,无法跨连接追踪。
别只盯 tmp_table_size,sort_buffer_size 和 read_rnd_buffer_size 同样关键
很多人调大 tmp_table_size 就以为万事大吉,但临时表的生命周期涉及多个缓冲区:
-
tmp_table_size和max_heap_table_size必须设为相同值,否则以较小者为准;设太高可能引发 OOM,建议从 64M 起步,按需递增 -
sort_buffer_size影响排序阶段能否在内存完成,若Sort_merge_passes高,它比tmp_table_size更直接相关 -
read_rnd_buffer_size控制对临时表的随机读效率,值太小会导致大量Handler_read_rnd_next,建议设为 512K–2M - 所有这些参数都是会话级的,全局设置只影响新连接,已有连接不生效
最易被忽略的一点:这些缓冲区是“每个线程独占”的。如果并发线程数是 200,sort_buffer_size 设为 4M,光这一项就可能吃掉 800MB 内存——必须结合 Threads_connected 综合评估。










