MySQL分组聚合OOM时应调大tmp_table_size和max_heap_table_size而非sort_buffer_size；PostgreSQL需按并发和操作数合理设work_mem；ClickHouse需联动max_threads配置max_bytes_before_external_group_by。
MySQL分组聚合OOM时，sort_buffer_size不是万能解药
直接调大 sort_buffer_size 往往无效，甚至让问题更糟。它只影响单个排序操作的内存分配，而大规模 GROUP BY 实际依赖的是 tmp_table_size 和 max_heap_table_size —— 这俩才决定内存临时表能撑多大。
常见错误现象：ERROR 1038 (HY001): Out of sort memory 或查询突然变慢、磁盘临时表暴增（/tmp/#sql_*.MYD 大量出现）。
-
tmp_table_size和max_heap_table_size必须设为相同值，否则以较小者为准 - 设太高可能触发系统OOM killer，尤其在多连接并发场景下；建议单次不超过物理内存的15%
- 仅对
MEMORY引擎临时表生效，一旦超限自动退化为磁盘MyISAM表，性能断崖下跌
PostgreSQL里work_mem调多少才不翻车
work_mem 是每个查询操作（如排序、哈希聚合）独享的内存上限，不是全局总配额。一个含 GROUP BY + ORDER BY + 窗口函数的查询，可能同时消耗 3×work_mem。
使用场景：OLAP类报表查询，数据量千万级，GROUP BY 字段基数高（比如按用户ID分组）。
- 线上环境慎用 >64MB 的
work_mem，20个并发就吃掉1.2GB内存 - 优先在会话级调整：
SET LOCAL work_mem = '128MB';，避免污染全局配置 - 配合
EXPLAIN (ANALYZE, BUFFERS)观察Peak memory usage，比拍脑袋设值靠谱得多
ClickHouse做分组聚合，max_bytes_before_external_group_by怎么设
这个参数是ClickHouse应对内存不足的“安全阀”：达到阈值后自动把中间结果写磁盘再归并。但它不是越大越好——设太大导致OOM，设太小则频繁落盘，IO成为瓶颈。
关键点在于它和 max_threads 联动：每个线程独立触发该限制，总内存消耗 ≈ max_threads × max_bytes_before_external_group_by。
- 默认值
0表示禁用外部聚合，强制全内存处理，极易OOM - 建议初始值设为单核可用内存的 1/3～1/2（例如64GB机器，
max_threads=16，则设max_bytes_before_external_group_by = 1000000000≈ 1GB） - 必须同步调大
max_bytes_before_external_sort，否则ORDER BY阶段仍可能失败
通用避坑：别忽略GROUP BY字段的数据类型和索引
再大的内存配置也救不了低效的分组逻辑。字符串 GROUP BY 比整型慢3～5倍，没索引的 WHERE 条件会让聚合前扫描放大数倍。
容易被忽略的地方：
- MySQL中
VARCHAR(255)分组比INT多出至少2次字符串比较开销，且无法利用前缀索引优化 - PostgreSQL里未在
GROUP BY字段建索引，会导致全表顺序扫描，work_mem再大也白搭 - ClickHouse的
ReplacingMergeTree表若没按GROUP BY字段排序，聚合效率直接打五折
内存只是最后一道防线，真正的瓶颈往往藏在数据模型和查询写法里。
