数百万分组不应在单次sql中完成，因group by需维护每组状态，超百万易致内存溢出、i/o暴涨、cpu飙升或直接报错；limit无效，必须前置高选择性where条件并避免函数索引失效。
直接说结论：数百万个分组本身就不该在单次 SQL 查询中完成——这不是优化能解决的问题，而是设计层面的信号。数据库执行 GROUP BY 时需维护每个分组的状态（如累加器、哈希桶），当分组数超百万，内存极易溢出，排序或哈希聚合都会退化，查询常卡死、OOM 或被强制 KILL。
为什么 GROUP BY 百万级分组会崩？
数据库引擎对分组的处理依赖内存和 CPU 局部性。常见行为包括：
- PostgreSQL 在
work_mem不足时 fallback 到磁盘哈希，I/O 暴涨； - MySQL 的
tmp_table_size和max_heap_table_size限制导致临时表写磁盘，Using temporary; Using filesort出现在EXPLAIN的Extra字段； - SQL Server 的
Hash Match Aggregate操作符在分组键基数过高时哈希冲突激增，CPU 占用飙升； - 所有主流引擎在分组数远超可用内存时，都会触发大量 swap 或直接报错，例如 PostgreSQL 的
ERROR: out of memory或 MySQL 的Lost connection during query。
WHERE 条件必须前置，且不能只靠 LIMIT
很多人误以为加 LIMIT 能缓解压力，但错在：数据库必须先完成全部分组，再排序+截断——LIMIT 对 GROUP BY 无提前终止作用。
真正有效的做法是把过滤逻辑压到最前：
- 用高选择性字段做
WHERE，比如status IN (1,2)、created_at >= '2026-06-01'，而非低选择性字段如country = 'CN'； - 避免在
WHERE中对字段用函数，例如DATE(created_at) = '2026-06-20'会让索引失效，应改写为created_at >= '2026-06-20' AND created_at ； - 如果业务允许，用分区裁剪（如按天/月分区表），让优化器跳过无关分区，
EXPLAIN中看到Partitions: p202606才算生效； - 确认统计信息最新：
ANALYZE table_name;（PostgreSQL）或UPDATE STATISTICS table_name;（SQL Server），否则优化器可能低估数据量，选错执行计划。
替代方案比“调优 SQL”更有效
当分组维度天然高基数（如 user_id、order_id、device_fingerprint），硬扛 GROUP BY 是徒劳。优先考虑以下路径：
- 用物化视图或汇总表预聚合：每天凌晨跑一次
INSERT INTO daily_user_summary SELECT user_id, COUNT(*), SUM(amount) FROM orders WHERE date = ... GROUP BY user_id，查询时直查汇总表； - 迁移到列存 OLAP 系统：ClickHouse 对千万级分组支持极好，
GROUP BY默认用 wide-column 哈希，配合FINAL或MATERIALIZED VIEW可吞吐百万分组/秒； - 应用层分片聚合：按
user_id % 100分 100 个子查询，每个查GROUP BY user_id HAVING user_id % 100 = N，应用合并结果——注意需自行处理空分组和精度问题； - 接受近似结果：PostgreSQL 的
approx_count_distinct()、ClickHouse 的uniqCombined()或 HyperLogLog 类算法，误差率 1%~2%，但响应时间从分钟级降到毫秒级。
真正容易被忽略的点是：分组数量不是由 SQL 决定的，而是由业务语义决定的。如果你的查询返回 200 万个分组，首先要问的是——这个结果真的要一次性拉到应用里吗？还是前端根本只展示 Top 100？后者只需改用窗口函数 + 子查询提前筛出 top-N，性能差异可达百倍。
