确认是否真在用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）极少必要。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
怎么安全地临时验证效果
别一上来就改 my.cnf 全局配置——线上环境容易翻车。正确做法是针对具体查询动态设置：
- 用优化器提示：
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 是最后一步微调，不是第一反应方案。
