为什么MySQL会报Out of sort memory错误以及如何调优配置-mysql教程-PHP中文网

Out of sort memory 错误源于单条查询排序时超出每个连接独占的 sort_buffer_size，而非全局内存不足；需先通过错误日志、应用异常、EXPLAIN 和精简字段验证是否真由排序内存触发，再针对性优化索引或字段。

为什么mysql会报out of sort memory错误以及如何调优配置

报 Out of sort memory 错误，**不是 MySQL 内存全局不足，而是单条查询在排序阶段撑爆了每个连接独占的 sort_buffer_size**。盲目调大这个值往往让问题更隐蔽、并发时更危险——先定位是不是真由它触发，再决定动不动参数。

别一看到报错就改配置。先查清楚源头：

检查 MySQL 错误日志（如 /var/log/mysql/error.log），确认完整报错含 Out of sort memory，而非 Query execution was interrupted 或 Server shutdown in progress —— 后两者说明是超时、被 KILL 或进程被 OOM Killer 杀掉
同步看应用日志：Spring 项目若抛出 java.sql.SQLException: Out of sort memory，才真正对应这个瓶颈；如果只是事务回滚但没这句异常，大概率是系统级 OOM 导致 mysqld 进程消失，得去 dmesg -T | grep -i "killed process" 里找证据
执行出问题的 SQL，去掉 ORDER BY 再试一次：如果不报错了，基本锁定是排序环节的问题

EXPLAIN 比调参快十倍，关键是看 Extra 列：

出现 Using filesort → 没走索引排序，MySQL 被迫把数据拉进 sort_buffer 排，必须加索引
出现 Using temporary; Using filesort → 同时触发临时表 + 文件排序，问题更重，优先检查 GROUP BY 或 DISTINCT 是否能覆盖
注意 MySQL 8.0 支持降序索引：ORDER BY created_at DESC, id ASC 要建 INDEX(created_at DESC, id ASC) 才能完全覆盖；只建 (created_at, id) 可能仍触发 Using filesort

MySQL 8.0.20+ 默认把 JSON、GEOMETRY 字段以 packed addons 方式加载进 sort_buffer，哪怕只取 10 行，单条 JSON 几 MB 就会直接冲垮默认 256KB 缓冲：

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

验证方法：把原 SQL 的 SELECT * 改成只选排序字段和主键，例如 SELECT id, created_at FROM t WHERE ... ORDER BY created_at DESC LIMIT 20 —— 如果不报错了，就是大字段拖累
估算是否溢出：AVG(LENGTH(json_field)) × 排序行数 > sort_buffer_size → 铁定溢出（用 SHOW VARIABLES LIKE 'sort_buffer_size' 查当前值）
别急着设成 4M：100 个活跃连接就吃掉 400MB，还可能触发 mmap 分配拖慢性能；删字段或加覆盖索引比调参管用得多

这个参数是每个连接独占的，不是全局共享，且只在需要排序时才分配：

它不会复用，也不会释放给其他连接；高并发下容易变成内存黑洞
设为 8M 看似保险，但 200 个连接同时跑分页排序，瞬间就占掉 1.6GB —— 很可能触发系统级 OOM
临时调整用 SET SESSION sort_buffer_size = 4*1024*1024（仅当前会话），比 SET GLOBAL 更安全；永久修改写入 my.cnf 的 [mysqld] 段，但务必结合 max_connections 估算上限
真正难处理的是那种“WHERE 过滤弱 + ORDER BY 字段无索引 + 返回大字段”的组合——这时候加索引、精简字段、改查询逻辑，比调参重要十倍

最常被忽略的一点：即使表只有几条数据，只要排序字段包含未压缩的 JSON 且单条超 256KB，Out of sort memory 就会立刻报出来。这不是数据量问题，是字段结构和 MySQL 8.0.20+ 排序策略共同作用的结果。