MySQL排序内存溢出时，sort_buffer_size并非越大越好，因其是每线程独占而非全局共享，盲目调大会导致OOM；90%问题实为缺失合适索引引发filesort，应优先优化索引而非调参。
MySQL排序内存溢出时，sort_buffer_size不是越大越好
直接调大 sort_buffer_size 常常让问题更糟——它不按查询分配，而是每个需要排序的线程都独占一份。100个并发排序查询，设成 32MB，瞬间就吃掉 3.2GB 内存，触发 OOM 或被系统 kill。
常见错误现象：MySQL server has gone away、Lost connection to MySQL server during query、mysqld got signal 11（段错误），日志里还夹着 Out of memory; check if mysqld or some other process uses all available memory。
-
sort_buffer_size是 per-thread 参数，不是全局共享池 - 默认值通常 256KB，对小结果集够用；盲目设到 4MB+ 在高并发下极易翻车
- 它只在需要排序（
ORDER BY、GROUP BY、DISTINCT）且无法走索引时才真正分配 - InnoDB 行格式（尤其是
COMPRESSED或大TEXT字段）会让实际内存占用远超预期
先确认是不是真要排序，还是索引没建对
90% 的“排序内存溢出”其实根本不需要调 sort_buffer_size —— 因为查询本可以走索引完成排序，却走了 filesort。
使用场景：执行 EXPLAIN 看 Extra 列是否含 Using filesort；再结合 SHOW PROFILE FOR QUERY N 看 Sorting result 阶段耗时占比。
- 复合索引顺序必须严格匹配
ORDER BY字段顺序（如ORDER BY a, b→ 索引需为(a, b)，(b, a)无效） -
WHERE条件字段 +ORDER BY字段可合并进一个联合索引（如WHERE status=1 ORDER BY created_at→ 建(status, created_at)） - 避免在
ORDER BY中使用函数或表达式（如ORDER BY UPPER(name)），会强制 filesort - 覆盖索引能同时满足查询和排序，避免回表，也减少排序数据量
实在要调 sort_buffer_size，得按负载场景分层设
全局统一设一个值是最大误区。OLTP 和 OLAP 查询混合部署时，小事务要快，报表类查询要稳，必须区分对待。
性能影响：该参数调太高，不仅挤占 InnoDB buffer pool，还会增加线程创建开销；太低则频繁写临时文件（/tmp），IO 暴涨。
- 线上 OLTP 主库：保持默认 256KB～1MB，靠索引优化解决排序
- 专用报表从库：可在会话级临时加大，如
SET SESSION sort_buffer_size = 8388608;（8MB），跑完即释放 - 绝对不要在配置文件里设超过 4MB，尤其当
max_connections > 200 - 监控
Sort_merge_passes状态变量：持续上升说明排序频繁落盘，但得先排除索引问题，而不是急着加内存
tmp_table_size 和 max_heap_table_size 也得同步看
排序只是冰山一角。如果排序前还要 GROUP BY 或 DISTINCT，MySQL 可能先建内部临时表——这时 tmp_table_size 才是瓶颈，不是 sort_buffer_size。
兼容性影响：MySQL 8.0+ 默认用 TempTable 存储引擎，对内存管理更激进；老版本用 MEMORY 引擎，受 max_heap_table_size 限制更死。
- 两个参数必须设为相同值，否则以较小者为准
- 查
Created_tmp_disk_tables / Created_tmp_tables比值，> 10% 就说明临时表频繁落地磁盘 -
SELECT ... GROUP BY中若含大字段（如JSON、TEXT），哪怕只取前 10 行，也可能因字段长度超限直接写磁盘 - 临时表写磁盘路径由
tmpdir控制，确保它不在系统盘且空间充足
