增大 sort_buffer_size 有时反而让排序更慢，因为MySQL为每个连接独占分配该内存，导致内存浪费、线程启动变慢及高并发下内存爆炸；真正需调大的信号是Sort_merge_passes持续上涨。
为什么增大 sort_buffer_size 有时反而让排序更慢
直接调大 sort_buffer_size 并不总能加速 ORDER BY，尤其当单次查询只用到很小一部分缓冲区时。MySQL 为每个需要排序的连接**独占分配**该内存，哪怕只排 10 行数据，也会预先分配完整大小。这会导致：内存浪费、线程启动变慢、高并发下内存爆炸式增长。
实操建议：
- 先用
SHOW PROFILE FOR QUERY N或EXPLAIN FORMAT=JSON确认是否真在走filesort（看Extra字段含Using filesort） - 查
SHOW GLOBAL STATUS LIKE 'Sort_merge_passes'：值持续上涨说明磁盘归并频繁，才是调大sort_buffer_size的合理信号 - 初始调整建议从
256K→1M试起，避免一步跳到4M以上
如何判断当前 sort_buffer_size 是否够用
关键不是看“有没有 filesort”，而是看它是否被迫写临时文件。MySQL 内部用一个阈值控制：当待排序行的总大小（行长度 × 行数）超过 sort_buffer_size，就会切分块、写磁盘、再归并——这就是 Sort_merge_passes 的来源。
实操建议：
- 用
SELECT @@sort_buffer_size查当前会话值（注意：它不继承全局值，会话内可动态改，但仅对后续排序生效） - 对典型慢查询加
SELECT /*+ SET_VAR(sort_buffer_size = 2097152) */ ... ORDER BY ...做对比测试 - 观察
Sort_scan（全缓冲区内完成）和Sort_range（索引范围扫描后排序）的比值，若后者远高于前者，优先考虑加索引而非调缓冲区
sort_buffer_size 和 max_length_for_sort_data 的协同关系
这两个变量共同决定 MySQL 用哪种排序算法：rowid 模式还是 full_columns 模式。前者只存排序字段+主键ID，省空间但需回表；后者把所有 SELECT 字段全读进缓冲区，省IO但吃内存。默认 max_length_for_sort_data=1024，意味着单行排序数据超 1KB 就自动切到 rowid 模式。
实操建议：
- 如果
EXPLAIN显示Using filesort且key_len很小，但返回字段很多，可能是max_length_for_sort_data过低触发了低效的rowid排序 - 调大
max_length_for_sort_data（如设为4096）有时比调sort_buffer_size更有效，尤其当排序字段短、但SELECT *返回宽表时 - 二者要一起压测：单独调大
sort_buffer_size却卡在rowid模式，等于白忙
线上环境调整 sort_buffer_size 的安全边界
这个变量是**会话级**的，但默认由全局值初始化。线上不敢乱动全局值？那就聚焦在具体 SQL 上做精准干预。
实操建议：
- 禁止在
my.cnf里设全局sort_buffer_size超过2M，尤其当max_connections > 200时，内存风险极高 - 对已知重排序的慢查询，在应用层 SQL 前加
SET SESSION sort_buffer_size = 2097152;（注意：必须在同连接内、查询前执行） - 监控
Threads_created：如果调大后该值飙升，说明新连接创建开销变大，可能触发连接池抖动
真正卡住性能的，往往不是缓冲区大小本身，而是没意识到排序算法选择、索引覆盖、字段宽度这些前置条件已经决定了缓冲区能发挥多大作用。
