确认当前排序真用了sort_buffer_size，需同时满足：explain显示using filesort且type为index/range但key_len很小，或排序字段为text/json/超长varchar；同时sort_merge_passes持续上涨（如每秒>1），而select @@sort_buffer_size可查会话级当前值。
调大 sort_buffer_size 不会自动让排序变快，它只在 MySQL 真触发 Using filesort 且排序数据能塞进内存时起作用；多数情况下，加索引比调这个参数更有效、更安全。
怎么确认当前排序真用了 sort_buffer_size？
MySQL 只有在无法用索引完成排序时才分配这个 buffer。别看 EXPLAIN 里有 Using filesort 就动手改参数——得先确认它是不是“真需要”：
-
EXPLAIN SELECT ... ORDER BY ...的Extra列出现Using filesort，且type是index或range，但key_len很小（比如索引长 3 列，只用了第 1 列），说明索引没覆盖排序字段 - 排序字段是
TEXT、JSON或超长VARCHAR(2000)，InnoDB 可能直接跳过索引走 filesort - 执行
SHOW GLOBAL STATUS LIKE 'Sort_merge_passes'，值持续上涨（比如每秒 > 1）才是磁盘归并频繁的硬证据；如果为 0 或极低，调大纯属浪费内存 -
SELECT @@sort_buffer_size查当前会话值（注意不是@@global.sort_buffer_size），默认通常是262144（256KB）
为什么设成 4MB 反而更慢甚至报错？
sort_buffer_size 是 per-connection 独占分配的，不是共享池。设高了不加速，只提前占内存：
- 哪怕只排 10 行数据，MySQL 也会按配置值（比如
4194304）一次性分配整块内存 - 100 个并发连接 × 4MB = 400MB 静态占用，但其中可能只有 3～5 个真在排序
- 线程启动变慢（尤其旧版本用
mmap分配大内存）、内存碎片增加、OOM 风险上升，小内存机器或容器环境特别明显 - MySQL 8.0.22+ 已禁止
SET GLOBAL sort_buffer_size，改了配置文件也得重启才对新连接生效，旧连接完全不受影响 - 报
Out of sort memory不一定缺内存——更可能是单行太大（比如 JSON 字段含 Base64 图片），这时调 buffer 没用，得先设max_sort_length或改查询逻辑
怎么安全地临时调参验证效果？
线上环境别一上来就改 my.cnf 全局配置——容易翻车。优先走会话级动态设置：
- 对单条慢查询加 hint 测试：
SELECT /*+ SET_VAR(sort_buffer_size = 2097152) */ id, name FROM users ORDER BY name LIMIT 1000 - 当前会话生效：
SET SESSION sort_buffer_size = 2097152，仅影响后续语句 - 调完立刻验证：
SHOW PROFILE FOR QUERY N看排序阶段耗时是否下降，同时盯紧Sort_merge_passes是否回落 - ORM（如 Django、Laravel）常在连接初始化时重置会话变量，需在 query 前显式
SET SESSION，否则白设 - 别和
innodb_sort_buffer_size混：后者只在建索引或大批量INSERT时用，跟SELECT ORDER BY完全无关
容易被忽略的协同参数：max_length_for_sort_data
sort_buffer_size 不是孤立工作的。它和 max_length_for_sort_data（默认 1024 字节）共同决定 MySQL 用哪种排序算法：
- 如果单行参与排序的数据（比如
SELECT * + ORDER BY short_col）超过该值，MySQL 自动切到 rowid 模式（只存排序字段 + 主键，再回表） - 此时增大
sort_buffer_size效果有限——得同步调大max_length_for_sort_data（比如设为4096）才能让 full_columns 模式生效 - EXPLAIN 同时出现
Using filesort和Using where，且回表量大，才值得考虑微调read_rnd_buffer_size；但它默认比sort_buffer_size小，别一起拉高 - 真正卡顿的大规模排序，根源往往不在缓冲区大小：优先加覆盖索引（比如
SELECT id, name FROM users ORDER BY status, created_at，建INDEX idx_status_created (status, created_at, id, name)）
最常被漏掉的一点：这个参数对 GROUP BY、DISTINCT、UNION 完全无效——那些靠的是 tmp_table_size 和 max_heap_table_size，而且这两个值必须相等才有效。
