应先确认是否真有using filesort：用explain查看extra列，若出现该提示且索引未覆盖排序字段（如字段超长、类型为text或缺少复合索引），才需调整；否则调大纯属浪费内存。
怎么确认真需要调 sort_buffer_size
别一看到 Using filesort 就急着改参数。先跑 EXPLAIN SELECT ... ORDER BY ...，重点看 Extra 列是否含 Using filesort，再结合 type 和 key_len 判断：如果 type 是 range 或 index，但 key_len 很小（比如只用了索引前 1 列），说明索引没覆盖排序字段；如果排序字段是 TEXT 或超长 VARCHAR(2000)，InnoDB 可能直接跳过索引走 filesort——这时调 sort_buffer_size 才有意义。
为什么设大了反而更慢
sort_buffer_size 是每个连接独占分配的内存，不是共享池。设成 8388608（8MB），哪怕只排 10 行数据，MySQL 也会为这个连接预分配 8MB。线上并发 200，就固定吃掉 1.6GB 内存，还没算其他 buffer。更糟的是旧版本（
- 查当前值：
SELECT @@sort_buffer_size（注意是会话级，不继承全局） - 观察关键指标：
SHOW GLOBAL STATUS LIKE 'Sort_merge_passes'，持续上涨才是缓冲区不够的信号 - 别只盯着
Using filesort——如果Sort_scan远高于Sort_range，说明排序本身频次低，优先加索引
怎么安全地临时调高
线上环境禁止写死在 my.cnf 里全局改。正确做法是针对具体查询动态设置：
- 用优化器提示：
SELECT /*+ SET_VAR(sort_buffer_size = 4194304) */ * FROM t ORDER BY c LIMIT 1000; - 或会话内先设再查：
SET SESSION sort_buffer_size = 4194304; SELECT ... ORDER BY ...; - 建索引时可临时加大：
SET SESSION sort_buffer_size = 8388608; ALTER TABLE t ADD INDEX idx_x (x); - 千万级表建索引，2MB～16MB 是实测较稳区间；OLTP 查询默认 256KB 够用，万行排序可试 1MB～4MB
调完立刻验证：SHOW PROFILE FOR QUERY N 看排序阶段耗时是否下降，同时盯紧 Sort_merge_passes 是否回落。
容易被忽略的协同参数
sort_buffer_size 不是孤立工作的。它和 max_length_for_sort_data 共同决定排序模式：后者默认 1024 字节，若单行参与排序的数据（比如 SELECT * + ORDER BY short_col）超过该值，MySQL 自动切到 rowid 模式（只存排序字段+主键，再回表），此时增大 sort_buffer_size 效果有限——得同步调大 max_length_for_sort_data（比如设为 4096）才能让 full_columns 模式生效。
另外，read_rnd_buffer_size 管的是排序后回表取数据的缓冲，只有执行计划同时出现 Using filesort 和 Using where 时才可能成为瓶颈，别和 sort_buffer_size 混着调。
