最直接判断SQL是否触发磁盘临时表的方法是查看SHOW PROCESSLIST中状态是否为“Copying to tmp table on disk”或长时间“Creating tmp table”；配合Performance Schema的SUM_CREATED_TMP_DISK_TABLES指标、EXPLAIN的Using temporary提示及全局状态差值验证可精准定位。
查当前会话是否正在写磁盘临时表
执行中 SQL 是否已触发磁盘临时表，最直接的线索是 SHOW PROCESSLIST 里状态字段。一旦看到 Copying to tmp table on disk 或 Creating tmp table 持续数秒以上，基本可以判定该查询正把中间结果往磁盘落。
注意：Copying to tmp table（无 on disk）只表示在用内存临时表，不等于安全；真正危险的是带 on disk 后缀的状态，说明已突破 tmp_table_size 和 max_heap_table_size 的较小值限制。
- 用
SELECT ID, INFO, STATE FROM information_schema.PROCESSLIST WHERE STATE LIKE '%tmp%';快速过滤可疑会话 - 如果
INFO字段为空，可能是权限限制，需用 root 或有PROCESS权限的账号执行 - 状态可能一闪而过，建议配合
pt-kill --busy-time 2 --print捕获长时卡住的临时表操作
通过 Performance Schema 定位具体语句
Performance Schema 能记录每条语句是否创建了磁盘临时表，比全局状态更精准。关键表是 events_statements_summary_by_digest，其中 SUM_CREATED_TMP_DISK_TABLES 字段就是你要找的指标。
执行以下查询可找出最近高频触发磁盘临时表的 SQL 模板：
SELECT DIGEST_TEXT, SUM_CREATED_TMP_DISK_TABLES, COUNT_STAR FROM performance_schema.events_statements_summary_by_digest WHERE SUM_CREATED_TMP_DISK_TABLES > 0 ORDER BY SUM_CREATED_TMP_DISK_TABLES DESC LIMIT 5;
- 结果中的
DIGEST_TEXT是去除了字面量的标准化 SQL，方便归类同类问题 - 若某条 SQL 的
SUM_CREATED_TMP_DISK_TABLES值远大于COUNT_STAR（比如 1000 vs 1），说明每次执行都落盘，不是偶发抖动 - 注意：该表默认只统计 digest 级别，不保留完整 SQL；如需原始语句，得开
events_statements_history_long并设足够大的performance_schema_events_statements_history_long_size
验证单条 SQL 执行计划里的 Using temporary
EXPLAIN 中出现 Using temporary 表示 MySQL 计划用临时表，但它不区分内存还是磁盘——这个判断要结合实际参数和数据量。但它是最早能预警的信号。
重点看三类场景：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
-
GROUP BY字段没索引、或用了函数（如GROUP BY JSON_EXTRACT(col, '$.name')）→ 必然落盘 -
ORDER BY字段与WHERE条件不共用索引，且排序结果集超过sort_buffer_size→ 可能触发 filesort + 临时表双重开销 -
UNION或子查询结果集大，且没走索引合并 → 很容易撑爆内存临时表上限
执行 EXPLAIN FORMAT=JSON SELECT ... 还能看到 used_memory 和 disk_reads（MySQL 8.0.22+），后者直接预估磁盘读页数，比“是否落盘”更量化。
对比全局状态确认是否真由这条 SQL 引起
单条 SQL 落盘本身不致命，但若它导致 Created_tmp_disk_tables 在几秒内突增几十次，就说明它在并发下放大了问题。上线前务必做这个交叉验证：
先记下当前值：
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
再执行目标 SQL 一次（最好在低峰期、单独连接中运行），立刻再查一次该状态值。差值就是这次执行新增的磁盘临时表数。
- 差值为 0：说明该语句没触发磁盘临时表（或被缓存优化绕过了）
- 差值 ≥ 1：确认是它引起的；≥ 5 则大概率存在分组键爆炸或字段过大问题（如 SELECT * + GROUP BY id）
- 如果差值远高于预期（比如执行一次却增加 50+），检查是否开启了
log_bin且语句被写入 binlog cache，那部分也可能计入临时表统计
真正难缠的是那些“单次不明显、但并发一上来就雪崩”的 SQL——它们往往在 Created_tmp_disk_tables 曲线里表现为毛刺，需要配合 pt-query-digest 分析慢日志中的 Rows_examined 和 Tmp_tables 字段才能揪出。
