Created_tmp_disk_tables与Created_tmp_tables用于统计磁盘/内存临时表创建次数，比值超25%表明临时表下盘率过高；需结合FLUSH STATUS、EXPLAIN及慢日志综合定位大临时文件成因。
查 Created_tmp_disk_tables 和 Created_tmp_tables 状态变量
MySQL 不直接暴露单条 SQL 生成的临时文件大小，但会统计会话或全局范围内内存/磁盘临时表的创建次数。这两个变量是第一道线索：Created_tmp_tables 表示所有临时表（含内存中）的创建次数，Created_tmp_disk_tables 表示其中落到磁盘的次数。只要后者 > 0，就说明有语句触发了磁盘临时表 —— 这通常意味着临时文件已生成，且大小可能远超 tmp_table_size 或 max_heap_table_size 的限制。
执行前先清空计数（仅限测试会话）：
FLUSH STATUS;再运行你的目标 SQL，然后查：
SHOW SESSION STATUS LIKE 'Created_tmp%';注意对比两个值的差值，差得越多，越可能产生大临时文件。
用 EXPLAIN 预判是否走磁盘临时表
EXPLAIN 的 Extra 列里出现 Using temporary 是明确信号，但不区分内存还是磁盘。真正决定落盘的是查询涉及的数据量和当前会话的内存限制参数。关键看三个条件是否同时满足：
- 查询包含
GROUP BY、DISTINCT、UNION或某些ORDER BY场景 - 结果集估算行数 × 平均行宽 >
tmp_table_size（会话级）和max_heap_table_size（取二者较小值） - 表结构含大字段（如
TEXT、BLOB、长VARCHAR），哪怕只选一列，也会强制走磁盘临时表
所以不能只看 Using temporary，要结合 rows 和字段类型一起判断。比如 SELECT DISTINCT long_text_col FROM t WHERE ...，哪怕 rows 很小，也大概率落盘。
开启慢日志并配置 log_queries_not_using_indexes=ON 捕获隐式落盘行为
有些语句不会在 EXPLAIN 中显示 Using temporary，但实际执行时因排序缓冲区不足（sort_buffer_size 太小）而生成磁盘排序文件（/tmp/MLIxxxxx）。这类行为不会被 Created_tmp_* 统计，但会被慢日志记录 —— 只要你在启动时加了：
slow_query_log = ON<br>log_queries_not_using_indexes = ON<br>long_query_time = 0然后执行语句，就能在慢日志里看到完整 SQL 和实际耗时，再配合
strace -p $(pgrep mysqld) -e trace=open,write（需 root）可观察是否真的打开了临时文件路径。
注意：线上慎开 long_query_time = 0，建议只在复现环境临时启用；log_queries_not_using_indexes 本身不记录临时文件大小，但它能帮你定位到那些“看起来不重、实际很重”的语句。
查 information_schema.PROCESSLIST 中的 Info 和 State 字段
当语句正在执行且卡在临时表阶段时，SHOW FULL PROCESSLIST 可能显示 State: Creating tmp table 或 State: Copying to tmp table on disk。此时如果 Info 字段还能看到原始 SQL（未被截断），就基本确认它正处于生成临时文件的过程中。但这个状态转瞬即逝，需要快速抓取，或者用轮询脚本持续监控：
while true; do mysql -Nse "SELECT ID,USER,HOST,DB,COMMAND,TIME,STATE,INFO FROM information_schema.PROCESSLIST WHERE STATE LIKE '%tmp%';" | grep -v '^$'; sleep 0.5; done
这招对偶发性大临时文件问题最有效，尤其是你怀疑某条定时任务 SQL 在凌晨触发了磁盘爆满时。
临时文件大小本身不会被 MySQL 主动记录，它取决于语句逻辑、数据分布、会话参数和引擎实现细节。真正要定位“谁写了多大临时文件”，得靠组合手段：先用状态变量圈范围，再用 EXPLAIN 排逻辑，辅以慢日志和进程状态抓现场。最容易被忽略的是 max_heap_table_size 这个会话级参数 —— 它默认和全局同值，但应用连接池常会覆盖，导致同一 SQL 在不同连接里行为不一致。
