MySQL filesort内存不足时不会直接失败，而是降级为磁盘归并排序，导致性能断崖下跌；此时Sort_merge_passes飙升、临时文件暴涨，根本解法是建合适索引消除filesort而非盲目调大sort_buffer_size。
MySQL filesort内存不足时，查询不会直接失败，而是自动降级为磁盘归并排序，性能断崖式下跌——你看到的“慢”，其实是多次磁盘读写拖出来的。
Using filesort出现后，sort_buffer_size不够会发生什么
当EXPLAIN显示Using filesort，且结果集大小超过sort_buffer_size设定值时，MySQL会启动外排序（external sort）：先分批把数据载入内存排序，写入临时文件（如/tmp/#sql_*.MYD），再合并这些文件。这个过程涉及大量随机I/O，尤其在机械硬盘上，延迟从纳秒级跳到毫秒级。错误日志里不会立刻报错，但你会看到Sort_merge_passes值飙升，Created_tmp_disk_tables同步上涨。
- 单次filesort若需合并 3 个以上临时块，耗时通常翻倍以上
- 并发高时，多个查询同时写磁盘临时文件，IO争用加剧，可能卡住其他非排序查询
- 临时文件默认落在
tmpdir，若该目录所在分区空间不足，直接报Sort aborted: unable to write to tmpdir
为什么没报Out of sort memory，查询却卡死了
“没报错但极慢”比报错更常见——因为MySQL默认行为是尽力完成排序，而不是立即中断。只有当分配内存失败（比如系统拒绝mmap、或sort_buffer_size设得太大触发ptmalloc争用），才会抛Out of sort memory。更多时候，它默默在磁盘上跑归并排序，而你只看到响应时间从200ms变成8s。
- MySQL 5.7+中，
sort_buffer_size > 2KB即启用mmap分配，高并发下线程常卡在malloc/mmap系统调用上，SHOW PROCESSLIST里状态可能是Sorting result但不动 - 用
perf top或pstack抓现场，常能看到线程堆栈停在__libc_malloc或os_file_write - 此时
SHOW STATUS LIKE 'Sort_merge_passes'每秒持续>5次，就是明确信号
Sort aborted和Using filesort不是一回事
Sort aborted是排序阶段彻底失败（如磁盘满、内存分配失败、查询被KILL），而Using filesort只是说明“没走索引排序”，它本身不报错。很多DBA盯着Using filesort猛调sort_buffer_size，结果发现Sort_merge_passes没降，反而Threads_connected一高就OOM——因为根本问题不在buffer大小，而在是否必须排序。
- 建对索引能让
Using filesort直接消失，比如ORDER BY created_at DESC配INDEX(created_at DESC)（MySQL 8.0支持） - WHERE条件过滤后只剩几百行，再大buffer也白搭；但若过滤后还有50万行，再小的buffer也会落盘
- SELECT * + ORDER BY text_col，即使有索引，也会因行太宽撑爆buffer，改用
SELECT id再JOIN取详情更稳
真正要盯的不是“有没有filesort”，而是“为什么不得不filesort”——索引缺失、字段顺序错、用了函数、还是查询逻辑本身就在做无意义全量排序。buffer调参只是止痛药，索引和SQL重写才是手术刀。
