确认查询卡在“Copying to tmp table”时，应先用SHOW PROCESSLIST定位线程，再通过EXPLAIN分析执行计划，重点检查type、key、Extra字段是否显示全表扫描或Using temporary/Using filesort；接着用SHOW GLOBAL STATUS LIKE 'Created_tmp%'比对Created_tmp_disk_tables增长量以确认是否落盘，并结合@@tmp_table_size与@@max_heap_table_size判断内存限制是否不足——根本优化在于为JOIN、WHERE、GROUP BY、ORDER BY涉及字段补充联合索引，而非盲目调大内存参数。
如何确认查询卡在 Copying to tmp table
执行 SHOW PROCESSLIST 时看到状态为 Copying to tmp table 或更糟的 Copying to tmp table on disk，说明 MySQL 正在把中间结果写入临时表——这本身不是错误，但一旦落到磁盘，I/O 开销会陡增。关键要区分是“内存临时表”还是“磁盘临时表”，后者才是性能瓶颈主因。
检查方式：SHOW VARIABLES LIKE 'tmp_table_size' 和 SHOW VARIABLES LIKE 'max_heap_table_size'。这两个值取较小者，即为单个查询能使用的最大内存临时表容量。若中间结果超限，就会强制落盘。
- 两者默认通常只有 16MB（
tmp_table_size）和 128MB（max_heap_table_size），对含GROUP BY、ORDER BY、DISTINCT或多表JOIN的查询极易触发落盘 -
max_heap_table_size还影响 MEMORY 引擎表上限，不能只调tmp_table_size - 修改需用
SET GLOBAL，且新连接才生效；线上调大前务必确认服务器空闲内存充足，避免 OOM
为什么加索引比调大 tmp_table_size 更有效
单纯调高 tmp_table_size 只是缓解症状，不解决根源。真正让 MySQL 不得不建临时表的，往往是缺失关键索引导致的全表扫描 + 排序/分组逻辑无法下推。
典型场景：一个 LEFT JOIN 查询带 ORDER BY t.gmt_modified DESC LIMIT 10，但被驱动表（如 receive）的 order_no 没索引，MySQL 就必须先把所有匹配行捞出来，再在内存或磁盘上排序、去重、截断——这个过程必然走临时表。
-
EXPLAIN中出现Using temporary+Using filesort是强信号，说明优化器已放弃索引有序性，改用临时结构处理 - 关联字段（
ON条件）、WHERE条件字段、GROUP BY和ORDER BY字段，只要参与中间结果集生成逻辑，就应优先考虑联合索引覆盖 - 例如
SELECT ... FROM t LEFT JOIN r ON t.order_no = r.order_no WHERE r.status = 1 ORDER BY t.gmt_modified DESC，至少需要r(order_no, status)和t(gmt_modified)两个索引
哪些 SQL 模式天然容易触发临时表
不是所有临时表都能靠索引消除，有些语法结构 MySQL 必须用临时表实现语义。识别这些模式，才能决定是重构 SQL 还是接受开销。
-
GROUP BY和ORDER BY字段不一致：如GROUP BY user_id ORDER BY created_at DESC，无法复用同一索引完成分组与排序，必走临时表 -
SELECT DISTINCT配合非索引字段：即使有索引，若DISTINCT列未单独建索引或未被覆盖，仍可能建临时表去重 - 子查询中含
GROUP BY或ORDER BY：外层无法下推优化，内层结果常需暂存 - UNION 查询：每个分支结果集需合并去重，MySQL 默认使用临时表
这类情况调大 tmp_table_size 有一定收益，但更要评估是否真需要全部字段、能否提前过滤、是否可用物化视图或应用层聚合替代。
临时表问题排查的实操顺序
别一上来就改配置。真实线上问题里，80% 的 Copying to tmp table on disk 根源是索引缺失或 SQL 写法低效。
- 先用
SHOW PROCESSLIST抓到正在卡住的线程 ID，再用EXPLAIN FORMAT=JSON分析对应 SQL，重点看used_temp_tables、used_filesort、rows_examined - 检查
EXPLAIN的type是否为ALL或index，key是否为NULL，这是索引未命中的直接证据 - 用
SELECT @@tmp_table_size, @@max_heap_table_size确认当前会话实际生效值（注意会话级变量可能被覆盖） - 临时表是否落盘，最终取决于
Created_tmp_disk_tables状态变量增长量，用SHOW GLOBAL STATUS LIKE 'Created_tmp%'对比前后值最准
真正难的是多表关联时各表索引的协同设计——比如驱动表用了索引，但被驱动表没走索引，整个 JOIN 还是会膨胀出巨量中间行，临时表大小就失控了。这点很容易被忽略。
