别一上来就调大sort_buffer_size，它解决不了根本问题，反而可能放大内存压力或掩盖查询缺陷；应优先通过explain确认using filesort、建立覆盖索引、精简select字段来根治排序性能问题。
直接说结论：别一上来就调大 sort_buffer_size，它解决不了根本问题，反而可能放大内存压力或掩盖查询缺陷。
为什么调大 sort_buffer_size 常常无效甚至有害
很多人看到 Error 1038 (HY001): Out of sort memory 就立刻执行 SET GLOBAL sort_buffer_size = 4M，结果发现：
- 错误暂时消失，但并发一高，MySQL 内存使用猛涨，触发 OOM killer
- 单行含 JSON/TEXT 字段超 2MB，就算设成 16MB 也照样报错（因为 MySQL 8.0.20+ 对大字段默认走全字段排序）
- 没查
EXPLAIN，不知道真正瓶颈是缺失索引，盲目调参只是给慢查询“打补丁”
先确认是不是真需要调 sort_buffer_size
执行以下三步判断：
- 运行
EXPLAIN SELECT ... ORDER BY ...，看Extra列是否含Using filesort—— 如果有，说明没走索引排序，优先建索引 - 查当前值：
SHOW VARIABLES LIKE 'sort_buffer_size';，注意它是个**会话级变量**，全局设置只影响新连接 - 检查排序字段实际数据量：
SELECT AVG(LENGTH(sort_column)), MAX(LENGTH(sort_column)) FROM table;，如果单值就超 1MB，调sort_buffer_size没意义
真要调，必须避开这几个坑
调整不是填数字那么简单：
- 别用
SET GLOBAL sort_buffer_size = 100*1024*1024这种硬编码，应换算为字节后写进配置文件my.cnf，避免重启失效 - 计算内存上限：假设
max_connections = 200，当前sort_buffer_size = 2M，那仅排序缓冲就占200 × 2MB = 400MB，再叠加其他 buffer（read_buffer_size、join_buffer_size），很容易吃光物理内存 - MySQL 8.0.20+ 对 JSON/BLOB 字段默认启用全字段排序，此时
sort_buffer_size必须大于「单行所有 SELECT 字段总长度」，否则直接报错，不降级到磁盘排序
比调参更有效的三件事
绝大多数排序性能问题，靠改 sort_buffer_size 是治标不治本：
- 给
ORDER BY字段建联合索引，例如CREATE INDEX idx_user_time ON orders(user_id, create_time DESC);，让排序变索引扫描 - 把大字段（如 JSON）从
SELECT *中剔除，改用二次查询按需加载：SELECT id, user_id, create_time FROM orders WHERE ... ORDER BY create_time DESC LIMIT 10 - 用覆盖索引避免回表，例如
SELECT order_id, status FROM orders WHERE ... ORDER BY create_time→ 在索引里包含order_id和status
真正关键的不是缓冲区大小，而是让 MySQL 少排、快排、不排——sort_buffer_size 只是最后一道防线，不是第一张底牌。
