真正该先看索引是否覆盖ORDER BY字段，执行计划出现Using filesort才需调sort_buffer_size；没它却调大纯属浪费内存且易OOM，应优先建覆盖索引而非盲目调参。
别急着改 sort_buffer_size，90% 的“排序慢”根本不是它的问题——真正该先看的是索引是否覆盖 ORDER BY 字段，以及执行计划里有没有 Using filesort。
怎么确认是不是真需要调 sort_buffer_size
MySQL 只在无法用索引完成排序时才动这个 buffer。调它前必须验证两点：
- 用
EXPLAIN SELECT ... ORDER BY ...查Extra列：出现Using filesort才说明走内存/磁盘排序路径 - 检查
type是index或range，但仍有Using filesort→ 索引没覆盖排序字段（比如只建了(a)却ORDER BY a, b） - 字段是
TEXT、VARCHAR(2000)等超长类型，即使有索引，InnoDB 也可能因长度截断退化为filesort - 没出现
Using filesort却调大sort_buffer_size，纯属浪费内存，且高并发下易触发 OOM
怎么安全地临时调大 sort_buffer_size
它是会话级变量，每个连接独占一份，不复用。线上严禁直接写进 my.cnf 全局硬塞：
- 默认值通常是
262144（256KB），单位是字节，不是 MB - 先试
SET SESSION sort_buffer_size = 4194304（即 4MB），仅对当前连接后续排序生效 - MySQL 8.0+ 支持动态改全局：
SET GLOBAL sort_buffer_size = 4194304，但需 SUPER 权限，且重启失效 - 更稳妥的方式是用优化器提示：
SELECT /*+ SET_VAR(sort_buffer_size = 8388608) */ * FROM t ORDER BY c LIMIT 1000 - 避免设成 256MB 或 1GB —— 100 个并发连接就吃掉 25GB 内存，还没算其他 buffer
为什么调了 sort_buffer_size 却没变快
常见假阳性现象，本质是误判瓶颈位置：
- 改了
my.cnf但SHOW VARIABLES LIKE 'sort_buffer_size'还是旧值 → 客户端连接已建立，不会自动继承新全局值；需重连或显式SET SESSION - 中间件（如 ProxySQL）或 ORM（如 Django）可能在连接初始化时重置会话变量，覆盖你的设置
-
Sort_merge_passes持续上涨才是关键信号；如果它接近 0，说明压根没触发归并排序，调 buffer 没意义 - 单行排序字段超过
max_sort_length（默认 1024 字节），MySQL 会截断参与排序的内容，此时增大sort_buffer_size完全无效 - 混淆
sort_buffer_size和innodb_sort_buffer_size：后者只用于LOAD DATA或批量INSERT构建 B+ 树，和SELECT ORDER BY无关
最常被忽略的一点：调 buffer 前，先确认你是不是在给一个本可以走索引的查询“打补丁”。加覆盖索引（比如 INDEX(status, created_at) 配合 ORDER BY status, created_at）比调任何 buffer 都来得直接有效。
