应通过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_% 只知“用了”，不知“为什么用”或“卡在哪”。需要交叉验证：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

• 若 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：

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 综合评估。