GROUP BY卡死主因是执行计划退化而非内存不足，应先查执行计划、建匹配复合索引、避免函数干扰，并通过分片聚合、预聚合或物化视图等策略优化。
GROUP BY 卡死时先看执行计划，不是调参数就能解决
千万级以上表一跑 GROUP BY 就卡住，大概率不是内存不够，而是执行计划退化成了 Sort + GroupAggregate（PostgreSQL/SQL Server）或全表扫描+临时表（MySQL）。直接调 work_mem 或 sort_buffer_size 可能反而让并发查询吃光内存。
实操建议：
- 先用
EXPLAIN (ANALYZE, BUFFERS)（PG）或SET STATISTICS XML ON（SQL Server）抓真实执行路径，重点看Actual Total Time和是否出现Spill to disk - 确认分组字段有没有匹配的复合索引——顺序必须和
GROUP BY字段完全一致，且不能在字段上套函数（比如YEAR(order_date)就没法走索引） - 如果分组键基数极高（比如用户ID），HashAggregate 内存溢出风险大，可考虑加
WHERE过滤掉低频值，或提前用WHERE user_id IN (SELECT user_id FROM top_users)缩小数据集
动态分组字段不能直接拼进 GROUP BY，必须用 sp_executesql
GROUP BY @col_name 在 SQL Server 里根本通不过语法检查，报错是“必须声明标量变量”，不是运行时报错——解析阶段就拒掉了。硬拼字符串用 EXEC 极易被注入，列名含空格或中划线会直接崩。
安全拼法：
- 字段名必须过
QUOTENAME(@col_name)，再查INFORMATION_SCHEMA.COLUMNS确认存在 - 聚合函数名（如
SUM、COUNT）不能参数化，得白名单校验：IF @agg_func NOT IN ('SUM','COUNT','AVG') RAISERROR - 多字段拼接别手写逗号，SQL Server 2017+ 用
STRING_AGG(QUOTENAME(col), ', ')，老版本用FOR XML PATH('')+STUFF清头尾 - 动态 SQL 字符串里必须显式带
ORDER BY，排序字段同样要QUOTENAME包裹，否则结果顺序不可控
分段聚合比单次扫全表更稳，但要注意主键连续性
嵌套查询或单次 GROUP BY 在超大数据量下常因临时表爆内存崩溃。改用按主键区间分片处理，能控制每次内存驻留规模，也方便失败重试。
关键约束：
- 分片依据必须落在主键或有高效范围索引的字段上（如自增
id或created_at），否则BETWEEN会退化成全表扫描 - MySQL 的
cte_max_recursion_depth默认 1000，分片数超限会截断；PG 更推荐用GENERATE_SERIES()替代递归 CTE - 每段聚合后结果要物化到临时表，并对常用过滤字段建索引（比如
CREATE INDEX ON #tmp_agg (user_id, d)），否则后续 JOIN 效率极低 - 别指望分段后自动合并——
SUM(uv)可以直接加，但COUNT(DISTINCT user_id)必须用UNION ALL去重再算，否则重复计数
预聚合表不是银弹，得看实时性容忍度
物化视图（PG）或定时增量聚合（如每分钟跑一次 INSERT INTO agg_1min SELECT ... GROUP BY time_bucket('1 minute', ts), tag_id）能扛住高并发查询，但本质是拿延迟换性能。
选型要点：
- 秒级更新需求 → 别用 PG 的
MATERIALIZED VIEW，它刷新时旧数据不可见，且无法反映刷新窗口内的新写入 - 写入密集场景 → ClickHouse 的
ReplacingMergeTree配MATERIALIZED VIEW支持后台异步去重，更适合流式聚合 - OLTP 主库上建复杂聚合视图风险极大——哪怕加了索引，
SELECT COUNT(*) FROM view_name仍可能触发底层全表扫描 - 真正麻烦的从来不是写 SQL，而是字段合法性校验链：用户输入 → 系统视图验证 →
QUOTENAME转义 → 白名单过滤 → 动态组装 → 执行。漏一环，轻则报错，重则拖垮整个库
