根本原因是ORDER BY无法走索引，导致MySQL必须先全量扫描生成临时表再排序；一旦结果含TEXT/BLOB或超长字段，或tmp_table_size与max_heap_table_size不一致/过小，即强制落盘并耗尽内存与磁盘。
MySQL在执行排序时产生临时表并耗尽内存，根本原因不是“排序本身太重”，而是ORDER BY无法走索引，被迫先取全量数据、再在内存中建临时表、最后排序——一旦中间结果（比如带TEXT字段的行或大偏移量LIMIT）超过tmp_table_size与max_heap_table_size的较小值，就立刻落盘，同时吃光内存+IO+磁盘空间。
为什么EXPLAIN显示Using filesort还会触发Using temporary
这两个标记同时出现，说明MySQL既不能用索引完成排序（Using filesort），又无法边读边排（比如因SELECT *含大字段、或ORDER BY字段顺序与索引不匹配），只能先把所有候选行装进临时表，再对这张表排序。常见于：
-
ORDER BY a ASC, b DESC，但MySQL版本是5.7（不支持混合方向索引），即使建了(a,b)索引也退化为临时表 -
WHERE status = 'active' ORDER BY created_at，但只有status单列索引，created_at无覆盖 -
ORDER BY UPPER(name)或ORDER BY DATE(created_at)——函数导致索引失效，必然走临时表 -
SELECT * FROM t ORDER BY id LIMIT 100000, 20：哪怕只取20行，MySQL仍要先在内存里存满100020行再截断，极易溢出
TEXT/BLOB字段会让内存临时表直接失效
MEMORY引擎（旧版默认）和TempTable引擎（MySQL 8.0+ 默认）对大字段处理逻辑不同，但共性是：TEXT、BLOB、超长VARCHAR（如VARCHAR(5000)）无法存入内存临时表——MySQL会跳过内存阶段，直接创建磁盘临时表。这不是“撑爆”，是“禁止存”。验证方式：
- 执行
EXPLAIN SELECT content FROM posts ORDER BY created_at，若content是TEXT，Extra必现Using temporary - 即使
tmp_table_size设为2G，只要查询涉及TEXT，Created_tmp_disk_tables仍会涨 - 修复办法只有两个：改
SELECT content为SELECT id, title等小字段；或用SUBSTRING(content, 1, 200)截断
tmp_table_size和max_heap_table_size设得再大也没用？
设大参数确实能缓解，但前提是两个值严格相等，且没被并发冲垮。真实场景中常见失效原因：
- 只改了
tmp_table_size = 512M，但max_heap_table_size仍是默认64M → 实际阈值就是64MB - 高并发下，每个连接都按这个上限分配内存，200个连接 × 128MB = 25.6GB，远超物理内存，触发OOM Killer杀进程
-
tmpdir落在根分区（如/tmp），磁盘满后，MySQL连创建磁盘临时表都失败，卡死在Copying to tmp table on disk - 未验证生效：必须执行
SELECT @@tmp_table_size, @@max_heap_table_size确认返回值一致且单位是字节（如134217728 = 128MB）
真正卡住的从来不是单条SQL，而是Created_tmp_disk_tables持续上涨 + ibtmp1文件疯长 + /tmp分区写满三者叠加。调参只是给问题续命，索引是否覆盖ORDER BY字段、是否误选大字段、是否用了函数或隐式转换——这些才是第一现场。
