“磁盘排序溢出”本质是排序缓冲区不足导致落盘，调优需先排查索引缺失、未走索引或数据量过大等问题，再合理设置会话级sort_buffer_size（如4MB），优先通过联合索引、覆盖索引等SQL优化减少排序压力。
当SQL报表执行排序时出现“磁盘排序溢出”（如MySQL提示 Sort aborted: sort buffer overflow，或PostgreSQL中大量临时文件写入磁盘），本质是内存中的排序缓冲区（sort_buffer_size）不足以容纳待排序的数据集，导致系统被迫将中间结果落盘，大幅拖慢性能。调优核心不是盲目增大缓冲区，而是结合查询特征、数据量和服务器资源做精准平衡。
确认是否真为 sort_buffer 不足
仅靠报错日志不能直接断定是缓冲区太小——也可能是索引缺失、排序字段未走索引、或一次性处理数据量过大所致。建议按顺序排查：
- 用
EXPLAIN检查排序操作是否走了索引（关注Extra列是否含Using filesort）； - 查看实际排序行数：
SHOW STATUS LIKE 'Sort_merge_passes';（MySQL），数值持续升高说明频繁落盘； - 对比
Sort_scan和Sort_range，判断是全表扫描后排序，还是范围扫描后排序； - 在慢查询日志中抓取对应SQL，用
SELECT ... ORDER BY ... LIMIT 100测试小结果集是否仍溢出——若不溢出，说明问题出在数据规模而非配置。
合理设置 sort_buffer_size（MySQL）
sort_buffer_size 是**每个连接独占**的内存空间，不是全局共享。设得过大反而引发内存浪费甚至OOM，尤其在高并发场景下：
- 默认值通常为 256KB，对多数中小报表够用；可先尝试调至 2MB～4MB 观察效果；
- 避免全局设为 64MB 或更高——100个并发连接就吃掉 6.4GB 内存；
- 优先在会话级动态调整：
SET SESSION sort_buffer_size = 4194304;（4MB），仅影响当前报表SQL； - 配合
read_rnd_buffer_size（用于排序后回表读取）一并评估，两者不宜同时过大。
从SQL和索引层面减少排序压力
比调大缓冲区更高效的方式，是让排序尽量在索引内完成，避免额外排序开销：
- 为
ORDER BY字段建立联合索引，且把WHERE条件字段前置，例如：WHERE status=1 ORDER BY create_time DESC→ 建索引(status, create_time)； - 避免在排序字段上使用函数或表达式，如
ORDER BY UPPER(name)无法利用索引； - 用覆盖索引减少回表：把
SELECT中所有字段都包含进索引，避免排序后还要逐行回聚簇索引取数； - 对超大数据报表，考虑分页改用游标分页（
WHERE id > ? ORDER BY id LIMIT N），绕过深度偏移排序。
其他引擎与替代方案参考
不同数据库优化逻辑有差异，需区别对待：
-
PostgreSQL：没有
sort_buffer_size，但受work_mem控制（每个排序操作可用内存）。建议单次查询设为 4MB～16MB，同样需防高并发下总内存超标； -
SQL Server：依赖
max server memory和查询内存授予机制，可通过OPTION (QUERYTRACEON 9204)查看实际内存分配； - 终极手段：对固定周期报表，预计算排序结果存入汇总表，或用物化视图（如MySQL 8.0+ 的持久化CTE暂不支持，可用定时任务+临时表替代）。
