GROUP BY 仅是分组聚合工具，不支持直接数据挖掘；多字段分组导致行数暴涨源于笛卡尔式组合，需避免高稀疏字段并尽早过滤；TOP N 需嵌套窗口函数实现每组排名。
GROUP BY 本身不支持“数据挖掘”，它只是分组聚合工具；所谓多维度数据挖掘，实际是用 GROUP BY 搭配其他机制（如窗口函数、ROLLUP、子查询）完成探索性分析——直接写 GROUP BY a, b, c 只能出静态切片，挖不出趋势、TOP N、占比或同比环比。
GROUP BY 多字段分组时，为什么结果行数暴涨？
多字段组合会生成笛卡尔式分组键，比如 region（5个值）、category（20个）、week（52个），理论最大分组数就是 5×20×52 = 5200 行。但真实数据中，很多组合根本不存在（比如“西北区+生鲜+第53周”），所以实际结果远少于理论值。问题在于：一旦你加了低基数字段（如 is_promotion 只有 Y/N），分组数就翻倍，中间结果膨胀，内存和排序压力陡增。
- 先检查每个字段的唯一值数量：
SELECT COUNT(DISTINCT region), COUNT(DISTINCT category) FROM orders - 避免把高稀疏字段（如
sku_id）直接塞进 GROUP BY —— 它会让分组粒度细到单行，等于没聚合 - 用
WHERE尽早过滤再分组，比如WHERE order_date >= '2026-01-01'，别等 GROUP BY 后再 HAVING 筛
如何在 GROUP BY 结果里算 TOP N 类别？
GROUP BY 本身不能做“每组取前3”，ORDER BY ... LIMIT 3 是全表排序后截断，不是按组。必须用窗口函数嵌套：先分组聚合，再对聚合结果按指标排名。
- 错误写法：
SELECT city, category, SUM(sales) FROM orders GROUP BY city, category ORDER BY SUM(sales) DESC LIMIT 3→ 只返回全局销量前三，不是“每个城市各自的前三” - 正确流程：先聚合 → 再用子查询或 CTE 包裹 → 在外层加
ROW_NUMBER() OVER (PARTITION BY city ORDER BY SUM(sales) DESC) - 示例：
WITH ranked AS ( SELECT city, category, SUM(sales) AS total_sales, ROW_NUMBER() OVER (PARTITION BY city ORDER BY SUM(sales) DESC) AS rn FROM orders GROUP BY city, category ) SELECT city, category, total_sales FROM ranked WHERE rn <= 3;
GROUP BY + ROLLUP 能替代 OLAP 工具吗？
可以快速生成小规模汇总层级（比如 GROUP BY region, category WITH ROLLUP 会自动补上 region 总计、全表总计），但它不存状态、不预计算、不加速钻取，纯属语法糖。真正跑得动的多维分析，靠的是物化视图或专用 OLAP 引擎（如 ClickHouse 的 Cube 表、Doris 的 Rollup Index）。
-
WITH ROLLUP输出带NULL占位符的汇总行，业务 SQL 必须用IFNULL(region, 'ALL_REGIONS')清洗，否则 BI 工具识别不了层级 -
WITH CUBE会穷举所有维度组合（2ⁿ 种），3 个字段就生成 8 组结果，5 个字段就是 32 组 —— 数据量大时慎用 - ROLLUP 结果无法直接用于环比计算，因为缺失时间序列连续性（比如缺某周数据，不会自动补 0），得靠 LEFT JOIN 日历表补全
真正卡住人的从来不是 GROUP BY 语法，而是分组键是否业务可信、聚合后是否还能回溯明细、以及后续分析链路（排名/占比/趋势）能否无缝衔接——这些地方一松动，报表就失真，而且很难 debug。
