调整sort_buffer_size仅在无索引排序、行体积小、Sort_merge_passes高且内存充足时有效；它不替代索引，与innodb_sort_buffer_size无关，需配合max_sort_length并优先优化SQL和索引。
直接结论：调整 sort_buffer_size 对大规模排序有帮助，但仅在特定条件下有效——它不能替代索引，也不能解决单行超大字段导致的内存溢出；盲目调大会浪费内存，调太小则频繁落盘。
什么时候改 sort_buffer_size 真的有用？
它只在以下场景起作用：
- 查询带
ORDER BY（或GROUP BY），且无法走索引（比如排序字段无索引、或用了函数/表达式） - 需要排序的数据行数多、但每行体积不大（比如只排
INT或短字符串） - 观察到
Sort_merge_passes状态值持续升高（说明频繁归并磁盘临时文件） - 服务器内存充足，且该参数当前值明显小于实际排序所需（例如默认 256KB，但你常要排 10 万行整数）
如果排序字段已有合适索引，sort_buffer_size 再大也用不上——MySQL 直接按索引顺序读取，不进排序缓冲区。
sort_buffer_size 和 innodb_sort_buffer_size 别混了
这是两个完全无关的参数：
-
sort_buffer_size是查询层的，影响SELECT ... ORDER BY的内存排序行为 -
innodb_sort_buffer_size是 InnoDB 引擎层的，只在INSERT/CREATE INDEX批量写入时用于构建 B+ 树索引的内部排序，和查询排序无关 - 修改
innodb_sort_buffer_size不会让ORDER BY变快，反之亦然
配置文件里如果同时写了这两个，别误以为它们协同工作——它们压根不在一个执行路径上。
怎么安全地调大？注意这三点
不是“越大越好”，必须结合线程数与单次排序需求估算：
- 它是每个会话独占的内存，不是全局共享。100 个并发连接 × 4MB = 400MB 实际占用，得算清楚
- MySQL 8.0.12+ 支持动态分配：即使设为 4MB，也不会一上来就 malloc 4MB，而是按需增长到上限；但旧版本是直接分配固定大小
- 必须配合
max_sort_length看——如果某行排序字段（比如JSON或TEXT）超过max_sort_length（默认 1024 字节），MySQL 会截断参与排序的部分，此时增大sort_buffer_size没意义，得先调max_sort_length
临时生效示例（只对当前语句）：SELECT /*+ SET_VAR(sort_buffer_size = 8388608) */ * FROM logs ORDER BY created_at DESC LIMIT 1000;
比调参数更有效的优化手段
真正卡顿的大规模排序，往往根源不在缓冲区大小：
- 加覆盖索引：比如
SELECT id, name FROM users ORDER BY status, created_at，建INDEX idx_status_created (status, created_at, id, name) - 避免
SELECT *排序：只查必要字段，减少单行体积，让同样大小的sort_buffer_size能塞下更多行 - 用游标分页替代
LIMIT offset, size：特别是 offset 很大时，ORDER BY ... LIMIT 100000, 20仍要扫前 10 万行排序，索引也救不了 - 确认是否真需要全量排序：业务上能否接受近似排序（如按时间分区后局部排序）？
最容易被忽略的一点：很多“慢排序”其实根本没触发 sort_buffer，而是因为 tmp_table_size 不够，导致中间结果先写成磁盘临时表，再对那个表排序——这时候调 sort_buffer_size 完全无效，得看 Created_tmp_disk_tables 状态值。
