MySQL强制使用磁盘临时表主因是MEMORY引擎不支持TEXT/BLOB类型，而非内存不足；只要ORDER BY、GROUP BY或SELECT含TEXT字段，优化器即弃用内存表，即使调大tmp_table_size和max_heap_table_size也无效。
TEXT/BLOB 字段直接参与排序或分组，MySQL 会强制用磁盘临时表
不是因为内存不够，而是 MEMORY 引擎根本不支持 TEXT/BLOB 类型。只要 ORDER BY、GROUP BY 或 SELECT 列表里出现 TEXT 字段（哪怕只取前 10 行），优化器就会跳过内存临时表，直奔 MyISAM 或 InnoDB 磁盘表。EXPLAIN 显示 Using temporary; Using filesort 且 type 是 ALL 或 key 为 NULL，基本就是它在作祟。
为什么改大 tmp_table_size 没用？
因为真正起作用的是 tmp_table_size 和 max_heap_table_size 中的较小值。常见错误是只调了前者，却让后者卡在默认 16MB —— 结果系统按 16MB 截断，200MB 的中间结果照常落盘。必须在 my.cnf 的 [mysqld] 段里显式写两行，且值完全相等：
tmp_table_size = 256M max_heap_table_size = 256M
重启前务必执行：
SELECT @@tmp_table_size, @@max_heap_table_size;
确认返回值一致且单位是字节（256M ≈ 268435456）。
哪些 SQL 写法会绕过参数限制，死磕磁盘？
-
ORDER BY UPPER(content)或GROUP BY JSON_EXTRACT(data, '$.title')：函数结果无法走索引，又带入 TEXT 类型，优化器无路可退 -
SELECT * FROM article ORDER BY created_at：即使created_at有索引，只要表里存在 TEXT 字段，整个临时表就无法驻留内存 -
GROUP BY SUBSTRING(content, 1, 100)：表达式本身不存索引，且 SUBSTRING 返回类型仍被视作 TEXT 上下文
不改表结构时怎么紧急止血？
核心是把 TEXT 字段从排序/分组逻辑中“摘出去”：
- 用已有的时间戳列替代内容排序，比如把
ORDER BY content_updated_at替掉ORDER BY SUBSTRING(content, 1, 1) - 加一个轻量摘要列，如
content_sha256 CHAR(64) GENERATED ALWAYS AS (SHA2(content, 256)) STORED，再建索引，然后ORDER BY content_sha256 - 必须按关键词密度排序？那就别在 SQL 层硬扛：先查出
id列表，在应用层或 Redis 中计算并排序，再用WHERE id IN (...)回查详情
最常被忽略的一点：即使你把两个 size 参数设到 1G，只要 SQL 里还带着 ORDER BY content，MySQL 就不会给你留一点情面——它不是没能力，是压根不许 MEMORY 引擎碰 TEXT。
