确认是否真在用sort_buffer_size做排序：先看EXPLAIN的Extra列有无Using filesort；若无，则该参数完全不参与排序；再查Sort_merge_passes是否持续>1，否则调参无效。

确认是否真在用 sort_buffer_size 做排序

改参数前先看 EXPLAIN 输出的 Extra 列有没有 Using filesort——没有它，sort_buffer_size 再大也完全不参与排序过程。常见误判点：索引存在但只覆盖了 WHERE 条件，没覆盖 ORDER BY 字段；或者排序字段是 TEXT、VARCHAR(2000) 这类长类型，InnoDB 会直接跳过索引走 filesort。

更关键的是查状态：SHOW GLOBAL STATUS LIKE 'Sort_merge_passes';。这个值每秒持续 > 1，才是磁盘归并频繁的硬证据。如果它几乎不动，说明当前排序压根没落盘，调参纯属白忙。

为什么设成 4MB 反而让查询更慢

sort_buffer_size 是每个连接独占分配的内存，不是共享池。哪怕你只排 10 行数据，MySQL 也会按配置值（比如 4194304）一次性把整块内存划给这个连接。

• 100 个并发连接 × 4MB = 400MB 静态占用，但其中可能只有 3～5 个真在排序
• 线程启动变慢、内存碎片增加、容器环境下容易触发 OOM
• 旧版本 MySQL 在分配大 buffer 时还会加锁，高并发下反而拖慢整体响应

默认值 262144（256KB）对多数 OLTP 查询已够用；万级行、单行体积小（如只排几个 INT 或短字符串），可试 1048576～4194304；超过 8388608（8MB）极少必要。

怎么安全地临时验证效果

别一上来就改 my.cnf 全局配置——线上环境容易翻车。正确做法是针对具体查询动态设置：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 用优化器提示：SELECT /*+ SET_VAR(sort_buffer_size = 2097152) */ id, name FROM users ORDER BY name LIMIT 1000;
• 或会话内先设再查：SET SESSION sort_buffer_size = 2097152;，然后执行目标 SQL
• 调完立刻盯两个指标：SHOW PROFILE FOR QUERY N 看排序阶段耗时是否下降，同时 SHOW GLOBAL STATUS LIKE 'Sort_merge_passes' 对比前后 30 秒增量

注意：Django、Laravel 等 ORM 常在连接初始化时重置会话变量，需在 query 执行前显式重设，不能依赖全局配置。

容易被忽略的协同参数

sort_buffer_size 不是孤立工作的。它和 max_length_for_sort_data 共同决定排序模式：

• 后者默认 1024 字节，若单行参与排序的数据（比如 SELECT * ORDER BY status）超过该值，MySQL 自动切到 rowid 模式（只存排序字段+主键，再回表）
• 此时增大 sort_buffer_size 效果有限——得同步调大 max_length_for_sort_data（比如设为 4096）才能让 full_columns 模式生效
• 另外，read_rnd_buffer_size 管的是排序后回表读取，如果排序后要回表大量数据，它也会成为瓶颈

真正减少磁盘排序，优先建覆盖索引、限制结果集、避免 SELECT *；sort_buffer_size 是最后一步微调，不是第一反应方案。