Out of sort memory 错误源于单条查询排序时超出每个连接独占的 sort_buffer_size，而非全局内存不足；需先通过错误日志、应用异常、EXPLAIN 和精简字段验证是否真由排序内存触发，再针对性优化索引或字段。
报 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 判断是否真需要内存排序
EXPLAIN 比调参快十倍，关键是看 Extra 列：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 出现
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
警惕 JSON / TEXT 字段在排序时“偷偷吃光”缓冲区
MySQL 8.0.20+ 默认把 JSON、GEOMETRY 字段以 packed addons 方式加载进 sort_buffer，哪怕只取 10 行，单条 JSON 几 MB 就会直接冲垮默认 256KB 缓冲：
- 验证方法：把原 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 分配拖慢性能；删字段或加覆盖索引比调参管用得多
调 sort_buffer_size 前必须看清它的行为边界
这个参数是每个连接独占的，不是全局共享，且只在需要排序时才分配：
- 它不会复用，也不会释放给其他连接；高并发下容易变成内存黑洞
- 设为 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+ 排序策略共同作用的结果。
