调大 sort_buffer_size 不能直接优化外部排序，仅影响内存排序阶段；真正减少磁盘归并需避免落盘，关键在是否触发 Using filesort、单行大小、并发数及 max_length_for_sort_data 是否导致双路排序。
调大 sort_buffer_size 不能直接“优化外部排序”，它只在内存排序阶段起作用；真正减少外部排序（即磁盘归并）的关键，是让排序尽量不落盘——而这取决于你是否真触发了 Using filesort、单行数据大小、并发连接数，以及有没有被 max_length_for_sort_data 暗中切到双路排序。
怎么确认当前排序真在用 sort_buffer_size？
很多人改了参数却没效果，是因为压根没走到排序缓冲区这一步。
- 先跑
EXPLAIN SELECT ... ORDER BY ...，看Extra列是否含Using filesort—— 没这个，sort_buffer_size再大也白搭 - 如果
type是index或range，但仍有Using filesort，说明索引没覆盖排序字段（比如ORDER BY created_at，但索引只有user_id） - 字段类型是
TEXT、JSON或超长VARCHAR（如VARCHAR(2000)），即使建了索引，InnoDB 也可能因长度限制退化为 filesort - 执行
SHOW GLOBAL STATUS LIKE 'Sort_merge_passes'：值持续上涨（比如每秒 > 1），才是磁盘归并频繁的硬证据
为什么设成 4MB 反而更慢？
sort_buffer_size 是 per-connection 独占分配的，不是共享池。设高了不加速，只提前占内存。
- 哪怕只排 10 行数据，MySQL 也会按配置值（比如
4194304）一次性分配整块内存 - 100 个并发连接 ×
4MB= 400MB 静态占用，但其中可能只有 3～5 个真在排序 - 线程启动变慢、内存碎片增加、OOM 风险上升，尤其在容器或小内存机器上更明显
- 默认值
262144（256KB）对多数 OLTP 查询已够用；万级行、单行 1048576（1MB）→4194304（4MB）
怎么安全地临时调参做验证？
别一上来就改 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，仅影响后续语句 - 查当前值：
SELECT @@sort_buffer_size（注意不是@@global.sort_buffer_size） - 监控变化：
SHOW GLOBAL STATUS LIKE 'Sort_merge_passes'对比调参前后 30 秒增量 - 避免 ORM 覆盖：Django、Laravel 等框架常在连接初始化时重置会话变量，需在 query 前显式
SET SESSION
容易被忽略的协同参数：max_length_for_sort_data
它和 sort_buffer_size 共同决定 MySQL 用哪种排序算法，直接影响内存用量。
- 默认值
1024，意思是：若 SELECT 字段总长度 > 1KB，自动切到双路排序（只存排序字段 + 主键 ID），省内存但多回表 - 如果你
SELECT *且含TEXT字段，哪怕sort_buffer_size设到 8MB，也会因单行超限被迫走双路，甚至直接报Out of sort memory - 优化方向优先是缩小 SELECT 字段（去掉不用的大字段），而不是盲目拉高
sort_buffer_size - 配合调整：
SET SESSION max_length_for_sort_data = 2048可延长单路排序适用范围，但要确保sort_buffer_size足够容纳额外字段
真正卡住排序性能的，往往不是缓冲区大小，而是单行体积过大、索引缺失、或 SELECT * 导致的隐式内存爆炸——这些地方改一行 SQL，比调十次 sort_buffer_size 更有效。
