GROUP BY 触发磁盘排序的直接原因是内存不足导致中间状态落盘，而非语法本身需要排序；常见根源包括 work_mem/sort_buffer_size 设置过小、索引未被有效利用（如最左前缀不匹配、范围条件后字段分组、非覆盖查询、隐式转换或函数滥用），三者叠加加剧溢出。
GROUP BY 触发磁盘排序的直接原因
不是 GROUP BY 语法本身要排序，而是它在执行时被迫落盘——当内存装不下分组中间状态，数据库就只能把哈希表或排序缓冲区写到磁盘。PostgreSQL 看到 Sort Method: external merge 或 HashAggregate Disk Usage > 0，MySQL 看到 Using temporary; Using filesort，基本就是磁盘排序已发生。
work_mem 或 sort_buffer_size 不够用
这是最常见、最容易被忽略的根源。这两个参数是「每个操作独占」的上限，不是全局共享池：
- PostgreSQL 的
work_mem：一个含GROUP BY的查询，可能同时触发 HashAggregate + ORDER BY + 窗口函数，每个都吃掉一份work_mem - MySQL 的
sort_buffer_size：只对当前连接生效，设太大易触发 OOM，设太小（比如默认 256KB）根本扛不住万级分组键 - 估算下限可参考：分组键数量 ×（键长度 + 指针开销）× 1.5；例如 10 万行、键长 20 字节 → 至少需 ~4MB
索引没被用于跳过排序阶段
即使建了索引，GROUP BY 仍可能走磁盘排序，因为优化器判定“用索引不如全扫+临时表”：
-
GROUP BY a, b但索引是(b, a)或单列(a)→ 最左前缀不匹配，无法利用物理有序性 - WHERE 中有范围条件，如
WHERE status = 1 AND created_at > '2025-01-01' GROUP BY user_id→user_id在范围字段之后，索引失效 - SELECT 中包含非索引覆盖字段，如
SELECT user_id, SUM(amount), MAX(note)，而索引只建了(user_id, amount)→note需回表，优化器放弃索引
隐式转换或函数让索引彻底失效
这类问题不会报错，但会让 GROUP BY 失去所有索引依托：
-
WHERE user_id = '123'（user_id是BIGINT）→ 字符串与数字比较触发隐式转换，索引失效 -
GROUP BY DATE(created_at)→ 函数强制逐行计算，无法走created_at索引 -
ORDER BY COUNT(*) DESC与GROUP BY共存 → 即使分组字段有索引，聚合结果仍需额外排序，且无法复用原索引顺序
work_mem + 索引设计 + 查询写法三者叠加失控的结果。调大内存只是治标，不修复索引顺序或隐式转换，换再大的 buffer 也迟早溢出。 
