sort_buffer_size 是 MySQL 单线程排序内存参数，影响 ORDER BY/GROUP BY 性能；过小导致频繁磁盘归并（Sort_merge_passes 上升、“Using filesort”），过大引发内存压力；建议 OLTP 设 2–4MB，OLAP 可会话级调高，并优先优化索引与查询。
sort_buffer_size 是 MySQL 中控制单个排序操作所分配内存的关键参数，直接影响 ORDER BY、GROUP BY、DISTINCT 等语句的执行效率和资源消耗。它不作用于整个实例，而是为每个需要排序的线程独立分配——也就是说，并发排序越多，总内存占用可能呈线性增长。
sort_buffer_size 如何影响排序行为
当排序所需数据量 ≤ sort_buffer_size 时，MySQL 在内存中完成快速排序（quicksort），性能最优；超过该值，则会启用外部排序：将数据分块排好后写入磁盘临时文件，再归并合并。这个过程涉及大量 I/O，性能明显下降，还可能触发磁盘临时表（如使用 tmpdir 目录）。
- 过小：频繁落盘，排序变慢，甚至出现 “Using temporary; Using filesort” 的 Extra 提示
- 过大：单线程占用内存高，高并发下易引发物理内存压力，导致系统 swap 或 OOM
- 默认值通常偏小（如 256KB），对现代硬件和常见查询往往不够用
如何判断是否需要调整
观察慢查询日志或 Performance Schema 中的排序相关指标：
- 检查 Sort_merge_passes 状态变量：数值持续上升，说明频繁归并，大概率内存不足
- 执行 EXPLAIN 查看 Extra 列是否含 “Using filesort” —— 注意这仅表示用了文件排序逻辑，不一定真写磁盘（若数据仍在 sort_buffer 内）
- 结合 Sort_scan 和 Sort_range 判断排序触发频次
调优建议与注意事项
调整需结合业务负载特征，避免“一刀切”：
- OLTP 场景：建议设为 2MB–4MB，兼顾并发与单次排序效率
- OLAP 或报表类查询较多时：可局部提高（如会话级 SET sort_buffer_size = 8M），避免全局设置过高影响连接数
- 不要盲目设到百 MB 级：MySQL 不会自动回收未用完的 sort_buffer，且大值无法复用，容易浪费
- 配合优化查询本身更有效：加索引覆盖排序字段（避免 filesort）、减少 SELECT *、限制 LIMIT 等
