Sort aborted 表示查询在执行 ORDER BY 或 GROUP BY 时排序阶段失败，主因是未走索引导致 filesort、内存不足、tmpdir 磁盘满或查询被中断；优先检查 EXPLAIN 是否出现 Using filesort 并建立合适索引，而非盲目调大 sort_buffer_size。
Sort aborted 错误到底意味着什么
这不是 MySQL 崩溃，而是某条查询在执行 ORDER BY 或 GROUP BY 时，排序阶段失败了。错误日志里出现 Sort aborted: Out of sort memory，说明 MySQL 尝试分配内存做排序，但失败了——要么系统真没内存，要么配置不合理，要么查询本身写法有问题。
直接调大 sort_buffer_size 往往适得其反
很多人第一反应是改 sort_buffer_size，但这个参数是 connection 级的，每个连接首次需要排序时就一次性分配指定大小。设成 10M 看似“更够用”，实际会触发 mmap 分配、拖慢性能，高并发下还容易耗尽物理内存。
-
sort_buffer_size超过 2KB 就切换为 mmap 分配，比 malloc 慢 - 并发连接数 ×
sort_buffer_size可能远超可用内存，引发 OOM 或 swap - MySQL 8.0 默认值通常是 256K，对多数中小查询已足够；盲目调到 2–3M 是较稳妥的上限
- 修改后必须重启 mysqld 才生效（
SET GLOBAL不影响已存在连接）
真正该优先检查的：索引是否覆盖排序字段
90% 的 Sort aborted 根源不在内存，而在 SQL 没走索引排序，被迫回表+文件排序。比如：
SELECT id, name FROM users ORDER BY created_at DESC LIMIT 20;
如果 created_at 没索引，或索引不是最左前缀匹配，就会触发 filesort；数据量一大，sort_buffer_size 再大也扛不住。
- 用
EXPLAIN查看Extra列：出现Using filesort就是危险信号 - 给排序字段建索引，例如
CREATE INDEX idx_created_at ON users(created_at DESC); - 复合查询要兼顾
WHERE和ORDER BY，如WHERE status=1 ORDER BY updated_at，索引应为(status, updated_at) - 注意 MySQL 8.0 支持降序索引，
ORDER BY a DESC, b ASC可用(a DESC, b ASC)索引完全覆盖
其他关键排查点不能漏
除了内存和索引，还有几个隐蔽但高频的原因：
- 临时目录
tmpdir磁盘满：df -h /tmp或查看my.cnf中tmpdir指向路径的剩余空间 - 查询被主动中断：日志里若含
Query execution was interrupted，大概率是客户端超时、应用层 cancel 或 DBA 手动KILL - 服务器正在关闭：
Server shutdown in progress属正常现象，不用处理，但需确认是否有人误操作重启 - 事务被 rollback：比如锁等待超时（
Lock wait timeout exceeded），这时查innodb_lock_wait_timeout和慢日志里的冲突 SQL
真正难缠的从来不是参数数字，而是搞不清「到底是内存不够，还是根本没走索引，还是磁盘/连接/事务层面出了岔子」——先看 EXPLAIN，再查 error log 全文，最后才动 sort_buffer_size。
