explain未报using temporary但show processlist卡在copying to tmp table，是因为explain仅预估执行计划、不模拟真实内存压力，而该状态是运行时行为——当中间结果集超过tmp_table_size与max_heap_table_size的较小值时，mysql才实际将内存临时表转为磁盘临时表。
为什么EXPLAIN没报Using temporary，但show processlist卡在Copying to tmp table
因为EXPLAIN只做执行计划预估，不模拟真实内存压力；而Copying to tmp table是运行时行为——当中间结果集大小超过tmp_table_size与max_heap_table_size中的较小值时，MySQL才实际把内存临时表转为磁盘临时表。
常见误判点：
- 看到
EXPLAIN里没出现Using temporary，就以为不会建临时表 → 实际可能因数据量突增（比如某天订单暴涨）或并发查询挤占内存，导致原本在内存的临时表被迫落盘 - 只盯
SHOW PROCESSLIST里当前状态为Copying to tmp table的线程 → 真正的“元凶SQL”可能已执行完、被kill，或正在排队等待IO - 误以为
tmp_table_size调大就能解决 → 忘了max_heap_table_size也必须同步调高，否则生效上限仍是两者中更小的那个
哪些SQL结构最容易触发磁盘临时表
不是所有GROUP BY或ORDER BY都危险，关键看是否能利用索引完成排序/分组，以及中间结果是否膨胀。以下结构高频踩坑：
-
SELECT *+GROUP BY：哪怕只返回10行，只要包含TEXT/BLOB字段，单行就可能超100MB，直接击穿内存限制 - 多表
JOIN后ORDER BY非驱动表字段：例如LEFT JOIN t1 ON t1.id = t2.t1_id ORDER BY t2.created_at，若t2.created_at无索引，MySQL必须先拼出全部JOIN结果再排序 -
GROUP BY多列且无覆盖索引：如GROUP BY a, b, c，但只有INDEX(a)，缺失b和c，优化器无法下推分组逻辑，只能走临时表 - 隐式类型转换：比如
JOIN条件一边是VARCHAR(50) CHARSET utf8mb4，另一边是VARCHAR(50) CHARSET latin1，强制全表扫描+临时表
怎么快速确认是不是磁盘临时表在拖慢服务
别只看状态，要抓指标变化和实时证据：
- 执行
SHOW GLOBAL STATUS LIKE 'Created_tmp%'，重点关注Created_tmp_disk_tables每秒增长量。如果>5次/秒，且Created_tmp_disk_tables / Created_tmp_tables > 0.2，说明超两成临时表已落盘 - 用
SELECT * FROM information_schema.PROCESSLIST WHERE STATE = 'Copying to tmp table'查实时线程，记下ID和INFO字段内容，立刻KILL掉长时间卡住的（比如Time > 30） - 临时开启会话级性能分析：
SET profiling = 1;，复现问题SQL，再用SHOW PROFILES;找耗时最长的ID，最后SHOW PROFILE FOR QUERY N;确认Copying to tmp table阶段是否占主导 - 检查
tmpdir磁盘使用率和IO等待：iostat -x 1看%util是否持续>90%，iotop确认mysqld进程是否在大量写/tmp或/var/tmp
调大tmp_table_size真能解决问题吗
能缓解，但治标不治本。盲目堆内存参数反而可能引发更严重问题：
- 每个连接独占一份
tmp_table_size内存，100个并发连接就吃掉100×256MB=25GB，容易触发OS OOM killer杀进程 - 即使设到512MB，遇到一个
GROUP BY百万行+TEXT字段的查询，照样落盘 -
max_heap_table_size还控制MEMORY引擎表上限，调它会影响其他业务逻辑 - 真正有效的解法是让MySQL根本不需要临时表：给
JOIN条件字段、WHERE过滤字段、GROUP BY和ORDER BY字段补联合索引，确保EXPLAIN中type为ref/range、Extra不出现Using temporary或Using filesort
最常被忽略的一点：tmp_table_size和max_heap_table_size必须设为相等，且修改后仅对新连接生效——老连接仍用旧值，重启或连接池滚动才能完全生效。
