group by大基数字段会因“分组数×单键体积”乘法效应撑爆内存，需用sha2等哈希或substring_index等截取替代原始大字段，并建立三段式索引确保using index for group-by。
GROUP BY大基数字段直接撑爆哈希表内存
数据库执行GROUP BY时，不是“边分组边丢弃”，而是把**每个分组键的完整值 + 对应聚合中间状态（如COUNT计数器、SUM累加值）**一起塞进内存哈希表。如果分组键是VARCHAR(2000)、TEXT或解析后的JSON字段，单个键就占几 KB；一千万个不同值，光键就吃掉 15–30 GB 内存——聚合计算根本没机会开始。
MySQL 和 PostgreSQL 都不会自动截断、哈希或压缩这些字段。你写GROUP BY description，它就原样存description全文；哪怕只SELECT COUNT(*)，也得把全部描述文本加载进哈希桶做比对。
-
EXPLAIN里看不到“大字段警告”，但Extra列出现Using temporary就是明确信号 - PostgreSQL 的
HashAgg节点若显示Spill to disk，说明work_mem已不够，但磁盘排序阶段仍需把全部分组键加载进内存 - JSON 字段、长 URL、HTML 片段、用户输入的富文本都属于高危类型，单键体积极易突破几 KB
调大tmp_table_size或work_mem只是拖延崩溃
参数调得再高，也无法改变“分组数 × 单键体积”这个乘法关系。设work_mem = '1GB'看似够用，但 50 个并发查询同时执行，就是 50 GB 内存需求，远超shared_buffers容量，反而引发系统级 OOM。
MySQL 中tmp_table_size和max_heap_table_size取较小值生效，只改一个等于白改；PostgreSQL 的work_mem是每个操作（如一个查询里的两个GROUP BY）各自独占，不是共享池。
-
sort_buffer_size完全无关——它只管ORDER BY，不干预GROUP BY的哈希表分配 - 即使 fallback 到磁盘（如 PostgreSQL 的
SORTAGG），排序阶段仍需加载全部分组键进内存，不是“自动落盘” - 盲目调参后
Created_tmp_disk_tables持续上涨，说明临时表已强制落盘，性能和稳定性都在恶化
真正有效的解法：让分组键变小、变稳定
别硬扛，要重构分组逻辑。核心原则是：用固定长度、确定性、可索引的表达式替代原始大字段。
- 对文本字段，用
GROUP BY SHA2(long_text, 256)（固定 64 字节），冲突概率可控 - 对 JSON，先提取关键路径再哈希：
GROUP BY SHA2(JSON_EXTRACT(data, '$.user_id'), 256) - 对 URL，用
GROUP BY SUBSTRING_INDEX(url, '/', 3)提取协议+域名，且确保该表达式能走函数索引（MySQL 8.0+/PG 12+） - 绝对避免
GROUP BY LEFT(long_text, 100)——它既不减内存占用，又让索引失效
隐性放大器：SELECT *和WHERE条件错位
你以为只GROUP BY大字段有问题？其实SELECT *会让临时表体积翻倍：数据库不仅要缓存分组键，还要为每组回表加载整行数据；而WHERE条件没下推到索引最左，就会导致全表扫描后再分组。
- 索引必须按三段式建：
WHERE等值字段 →GROUP BY字段 →SELECT中的聚合字段（如INDEX(status, user_id, amount)） - 执行计划中
Extra出现Using index for group-by才算成功；若仍是Using temporary; Using filesort，说明索引没命中 - 视图里含
GROUP BY会强制物化（DERIVED），哪怕外层只LIMIT 10，也会先把几百万行全载入内存
