GROUP BY大字段会直接撑爆内存，因数据库将整个字段值原样存入哈希表；500万分组×1.2KB/字段≈6GB仅键内存，加聚合值和哈希开销更甚；SHA2哈希或函数索引是可控解法。
GROUP BY大字段直接撑爆哈希表内存
数据库执行 GROUP BY 时，并不是只存分组键的“标识”，而是把整个字段值原样塞进内存哈希表做比对。一个 VARCHAR(2000) 字段平均占 1.2KB，若分组数达 500 万，光键就吃掉约 6GB 内存——还没算聚合值（如 SUM(amount)）和哈希桶开销。
常见错误现象：Out of memory、连接断开（MySQL 的 ERROR 2013）、PostgreSQL 的 out of memory detail: HashAgg；EXPLAIN 中出现 Using temporary 就已是危险信号，但此时已无法避免内存加载。
- MySQL 和 PostgreSQL 都不会自动截断或压缩
GROUP BY字段内容 - 哪怕只写
SELECT COUNT(*) FROM t GROUP BY big_text，big_text全量值仍被缓存 -
TEXT、JSON、长 URL 或 Base64 编码字段风险最高
调大 tmp_table_size 或 work_mem 只是延缓崩溃
设 work_mem = '1GB'（PostgreSQL）或 tmp_table_size = 536870912（MySQL）看似解法，实则埋雷：它不改变哈希表体积公式 分组数 × (键体积 + 聚合值体积)，只是把 OOM 时间点往后推。
真实限制更隐蔽：
- MySQL 中
tmp_table_size和max_heap_table_size取较小值生效，设 1GB 但另一项是 64MB，实际仍按 64MB 限制 - PostgreSQL 的
work_mem是每个操作独占，一个查询含 JOIN + GROUP BY + ORDER BY，可能申请三份，50 并发 × 256MB = 12.8GB - 即使 fallback 到磁盘（如 PostgreSQL 的
SORTAGG），排序阶段仍需把全部分组键加载进内存
用哈希或前缀替代原始大字段
真正可控的解法，是让分组键变小、确定、可索引。
对文本字段，优先用 SHA2() 或 MD5()：
SELECT SHA2(big_text, 256) AS hash_key, COUNT(*) FROM t GROUP BY SHA2(big_text, 256);
对 JSON 字段，提取后再哈希：
GROUP BY SHA2(JSON_EXTRACT(data, '$.user_id'), 256)
若必须按语义前缀分组（如域名），用 SUBSTRING_INDEX()，但确保建了函数索引：
- MySQL 8.0+：
CREATE INDEX idx_url_domain ON t (SUBSTRING_INDEX(url, '/', 3)) - PostgreSQL 12+：
CREATE INDEX idx_url_domain ON t ((SUBSTRING_INDEX(url, '/', 3))) - 绝对避免
GROUP BY LEFT(long_text, 100)—— 它既不减内存，又让索引失效
最容易被忽略的隐性放大器：SELECT * + WHERE 条件错位
你以为只改 GROUP BY 就够？其实 SELECT * 和低效 WHERE 会让哈希表体积翻倍甚至指数级增长。
-
SELECT *触发回表 + 全行加载进临时表，单行体积从几字节变成几 KB - 索引建了
(user_id)，但查询带WHERE status = 'paid'，实际仍是全表扫描 - 联合索引顺序错位：索引是
(status, created_date)，却写GROUP BY created_date, status→ 索引失效 - 函数干扰：写成
GROUP BY DATE(created_at)，索引完全无法使用
复杂点不在哈希算法本身，而在分组键与聚合值的体积乘积关系——一个字段变大 10 倍，内存压力就翻 10 倍；而索引错配或 SELECT * 可能再放大 5–20 倍。这没法靠加内存兜住。
