必须立刻干预优先减少排序需求确认是否真需ORDER BY、检查索引匹配性、避免函数排序其次调大tmp_table_size/max_heap_table_size会话级禁用ORDER BY RAND()改用ID范围查询或应用层随机。MySQL排序用到Using filesort且内存不足怎么办当EXPLAIN显示Extra列含Using filesort同时慢查询日志里出现Sort_merge_passes飙升或磁盘临时文件/tmp/#sql_*.MYD暴涨基本能确定是排序挤爆了sort_buffer_size——不是“该不该优化”而是“必须立刻干预”否则并发一高就卡死。别急着调大sort_buffer_size。这个参数是**每个连接独占**的设成 4MB 后 100 个连接就吃掉 400MB 内存可能直接触发 OOM。优先做减法确认是否真需要ORDER BY分页场景下LIMIT 10000,20这种偏移量大的排序99% 的数据都白排了改用游标分页WHERE id ? ORDER BY id LIMIT 20检查ORDER BY字段是否有索引联合索引要严格匹配最左前缀比如INDEX (a,b,c)能加速ORDER BY a,b但对ORDER BY b,c无效避免在ORDER BY里用函数或表达式ORDER BY UPPER(name)会强制 filesort哪怕name有索引临时表走磁盘而不是内存看tmp_table_size和max_heap_table_sizeMySQL 用内存临时表MEMORY引擎存中间结果但一旦结果集超过tmp_table_size或max_heap_table_size中**较小的那个值**就会自动转成磁盘临时表MyISAM或InnoDB性能断崖下跌。这两个值默认通常只有 16MB而一个带GROUP BY ORDER BY的查询很容易突破——尤其字段含VARCHAR(500)或TEXT时内存估算会更激进。查当前值SHOW VARIABLES LIKE tmp_table_size; 和 SHOW VARIABLES LIKE max_heap_table_size;临时调高仅会话级安全SET SESSION tmp_table_size 64*1024*1024;64MB真正有效的做法是让查询本身不生成大临时表比如把SELECT *改成只取必要字段GROUP BY前先用子查询过滤掉 90% 的行CREATE TEMPORARY TABLE ... ENGINEMEMORY不是万能解药有人想绕过优化器手动建内存表存中间结果再排序。这思路没错但ENGINEMEMORY表有硬伤不支持TEXT/BLOB字段且所有字符串字段按最大长度预分配内存VARCHAR(1000)当 1000 字节算极易触发The table is full错误。 稿定AI 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能