真正该先做的是检查EXPLAIN中是否出现Using filesort；只有确认该提示存在且排序无法走索引时，才需谨慎调整sort_buffer_size，否则纯属浪费内存并增加OOM风险。
别急着调大 sort_buffer_size，它大概率不是你查询慢或报错的根因——真正该先做的，是看 EXPLAIN 输出里有没有 Using filesort。
怎么确认是不是真需要动 sort_buffer_size
MySQL 只在无法用索引完成排序时才分配这个 buffer。常见触发场景包括：
• ORDER BY 字段没索引，或索引不满足最左前缀（比如 WHERE a = 1 ORDER BY b, c，但索引是 (a, d, c)）
• 排序字段类型是 TEXT、JSON 或超长 VARCHAR(2000)，InnoDB 因长度限制放弃索引排序
• 查询里对排序字段用了函数，比如 ORDER BY DATE(created_at)
• EXPLAIN 的 Extra 列出现 Using filesort，且 type 是 index 或 range ——这说明索引扫描了，但排序仍要额外做
没看到 Using filesort 却去调 sort_buffer_size，纯属浪费内存，还可能抬高 OOM 风险。
为什么调大后反而更慢甚至报 Sort aborted
这个参数是每个连接独占、按需一次性分配的：
• sort_buffer_size 超过 2KB 就走 mmap 分配，比 malloc 慢，线程启动延迟明显
• 设成 4MB 后，100 个并发连接就固定吃掉 400MB 内存，还没算其他 buffer
• MySQL 8.0.22+ 已禁止 SET GLOBAL 动态修改，改了配置文件也得重启才生效，旧连接完全不受影响
• 报 Out of sort memory 不一定缺内存，更可能是单行数据太大（比如 JSON 字段含 Base64 图片），这时调 buffer 没用，得先设 max_sort_length 或改查询逻辑
典型翻车操作：把 sort_buffer_size 从默认 262144（256KB）直接拉到 8388608（8MB），结果 Sort_merge_passes 没降，Created_tmp_disk_tables 反而涨了。
安全有效的调整方式
优先走会话级临时设置，避免全局污染：
• 查当前值：SELECT @@sort_buffer_size（注意单位是字节）
• 对单条慢查询临时加 hint：SELECT /*+ SET_VAR(sort_buffer_size = 4194304) */ * FROM t ORDER BY x LIMIT 100
• 线上稳妥起步值是 4MB（4194304），别一上来就 8M 或 16M
• 必须配合监控：SHOW GLOBAL STATUS LIKE 'Sort_merge_passes'，持续上涨才是调大的合理信号
• 如果 EXPLAIN 同时出现 Using filesort 和 Using where，且回表量大，再看要不要微调 read_rnd_buffer_size，但它默认比 sort_buffer_size 小，别一起拉高
• 别和 innodb_sort_buffer_size 混：后者只在建索引或大批量 INSERT 时用，跟 SELECT ORDER BY 完全无关。
比调 sort_buffer_size 更有效的三件事
缓冲区只是最后一道补救，优化应往前压：
• 给 ORDER BY 字段建覆盖索引，比如 WHERE status = 1 ORDER BY updated_at，对应索引 (status, updated_at)
• 避免 SELECT *，只查必要字段；宽表排序时，max_length_for_sort_data 比 sort_buffer_size 更关键
• 把大字段（JSON、TEXT）移出排序主路径，比如用子查询先取 ID，再 JOIN 补字段
真正卡住的大规模排序，90% 的解法不在内存参数里，而在索引设计和 SQL 收敛上。缓冲区调得再准，也盖不住一个缺失的复合索引。
