应先确认是否真有using filesort：用explain查看extra列，若出现该提示且索引未覆盖排序字段（如字段超长、类型为text或缺少复合索引），才需调整；否则调大纯属浪费内存。
sort_buffer_size 不是“提高性能”的万能开关，它只在 MySQL 真正触发 Using filesort 时才被分配，且每个连接独占一份内存。盲目调大反而容易引发 OOM —— 你得先确认是不是真需要它。
怎么判断要不要动 sort_buffer_size
别凭感觉调。先看执行计划里有没有 Using filesort：
- 用
EXPLAIN SELECT ... ORDER BY ...查Extra列，出现Using filesort才说明排序没走索引 - 如果
type是index或range却仍有Using filesort，大概率是索引没覆盖排序字段（比如VARCHAR(2000)字段建了索引但实际排序时被截断） - 查慢查询日志，如果某条语句反复报
Out of sort memory，那才是缓冲区真的不够用 - 没出现
Using filesort却去调sort_buffer_size，纯属浪费内存
改配置文件还是用 SET SESSION？
两者用途完全不同，选错就白忙：
- 写进
my.ini（Windows XAMPP 下路径通常是XAMPP\mysql\bin\my.ini）的[mysqld]段下，如sort_buffer_size = 2M，必须重启 MySQL 服务才对新连接生效 -
SET SESSION sort_buffer_size = 4194304（即 4MB）只影响当前连接，断开重连就还原，默认值通常是 262144（256KB） - MySQL 8.0.22+ 已禁止
SET GLOBAL sort_buffer_size，只能配文件或SET SESSION - 某些 ORM（如 Django）或中间件（如 ProxySQL）会重置会话变量，导致
SET SESSION生效后又被覆盖
设多大才算安全？
不是越大越好，关键看并发和总内存：
- 默认 256KB 对多数 OLTP 查询已够用；万级行排序可试 1M～4M；超过 8M 很少必要，且风险陡增
- 它是 per-connection 的：100 个并发连接 × 8MB = 800MB 静态占用，哪怕只有 5% 连接真用到它
- 低配机（比如 1GB 内存）设超 4M 就容易触发 swap 或 OOM
- 建索引时临时调高有用（如
SET SESSION sort_buffer_size = 8388608），但别全局写死 —— 空闲连接也占内存
真正容易被忽略的是：它只管 ORDER BY 排序，对 GROUP BY、DISTINCT、UNION 完全无效 —— 那些靠的是 tmp_table_size 和 max_heap_table_size，而且这两个值必须相等才有效。
