GROUP BY多列导致哈希表体积爆炸，本质是数据库将所有分组字段原始值与聚合中间结果全量缓存于内存哈希表；单行键超120字节×千万组合即耗1.2GB，尚未计入聚合状态；MySQL/PG均不压缩、不截断、不隐式优化函数表达式；EXPLAIN出现Using temporary即表明索引失效、已退化为全量内存哈希。
GROUP BY多列时哈希表体积爆炸的真实原因
不是“列多了就慢”，而是数据库把所有GROUP BY字段的原始值 + 每组聚合中间结果全量塞进内存哈希表。比如GROUP BY user_id, region, device_type, ip_address，其中ip_address是VARCHAR(45)、device_type是VARCHAR(64)，单行分组键就超120字节；一千万个不同组合，光键就吃掉1.2 GB内存——还没算SUM()或COUNT(DISTINCT)的中间状态。
MySQL 和 PostgreSQL 都不会自动截断或压缩这些字段，也不会对函数表达式做隐式索引优化。哪怕你只SELECT COUNT(*)，只要GROUP BY里有大字段或多字段组合，哈希表照样原样加载。
EXPLAIN里出现Using temporary就是明确信号：索引没覆盖分组逻辑，数据库已放弃索引分组，转为全量加载进内存哈希表。
哪些多列组合会让内存问题雪上加霜
常见高危模式不是“列多”，而是列之间缺乏基数控制和索引协同：
-
GROUP BY status, created_at, user_id：如果status只有3个值，但user_id有千万级，组合数≈千万×3，分组桶数直接爆炸 -
GROUP BY SUBSTRING(url, 1, 100), JSON_EXTRACT(data, '$.ref')：函数导致索引失效，且字符串截取无确定性（SUBSTRING不走索引），数据库无法预估分组数 -
GROUP BY region, category, subcategory, brand：四层维度未做降维，实际分组数远超业务需要，很多桶只有一两行却仍占内存 -
SELECT *配合多列GROUP BY：触发回表+全行缓存，单组内存占用翻倍，TEXT/BLOB列会直接迫使临时表落盘
真正有效的解法不是调work_mem或tmp_table_size
调参只是延缓崩溃，不能改变哈希表体积 = 分组数 × (每组键体积 + 聚合中间值体积) 这一本质公式。以下操作才直接影响分母和分子：
- 用联合索引强制走索引分组：
ALTER TABLE logs ADD INDEX idx_status_region_time (status, region, created_at)，确保GROUP BY status, region, created_at能命中Using index for group-by - 把高基数列换成低基数标识：
JOIN users u ON l.user_id = u.id GROUP BY l.region, u.tier，把千万级user_id映射成3档tier，分组桶从千万级降到个位数 - 用哈希替代长文本：
GROUP BY SHA2(description, 256), SHA2(tags, 256)，固定64字节/键，冲突可控，且支持函数索引（MySQL 8.0+/PG 12+） - 分片聚合再合并：
CREATE TEMPORARY TABLE tmp_ids (id BIGINT PRIMARY KEY); INSERT INTO tmp_ids SELECT id FROM logs WHERE ... LIMIT 50000;，再JOIN聚合，避免单次处理超阈值
最容易被忽略的隐性放大器
很多人查完执行计划没问题，一跑就OOM，问题往往藏在视图、子查询或客户端行为里：
- 视图定义含
GROUP BY，外层SELECT * FROM v LIMIT 10→ MySQL强制DERIVED物化，几百万行全进内存再截断 - PostgreSQL视图里写了
ORDER BY updated_at DESC，外层加LIMIT但没下推 → 全量排序后再取10条，work_mem再大也扛不住 - JDBC用
setFetchSize(Integer.MIN_VALUE)只解决客户端堆溢出，服务端仍要算完全部分组，内存照爆 -
WHERE条件字段没放进联合索引最左位置，比如索引是(region, created_at)，但查询写WHERE user_id = ? GROUP BY region, created_at→ 索引完全失效，退化为全表扫描+内存哈希
复杂点在于：问题常是多个因素叠加——比如多列GROUP BY + 视图物化 + SELECT * + WHERE未覆盖索引，这时候单改一个地方根本没用。得顺着EXPLAIN里的Using temporary或Hash Key线索，一层层剥开执行路径。
