GROUP BY字段过多是写统计类SQL时非常常见的问题。有些查询为了一个报表，在GROUP BY后面跟了十几个甚至几十个字段，结果要么直接触发数据库的限制，要么查询慢得离谱，要么在ONLY_FULL_GROUP_BY模式下报错。这篇文章就来聊聊这个问题的成因，以及两种主流的解决思路：简化业务逻辑和借助临时表分步聚合。
一、为什么GROUP BY字段会越堆越多
先看一段典型的失控SQL：
SELECT
d.dept_name,
u.city,
u.level,
p.product_name,
p.category,
DATE(o.create_time) AS order_date,
COUNT(o.id) AS order_count,
SUM(o.amount) AS total_amount
FROM orders o
JOIN user u ON o.user_id = u.id
JOIN department d ON u.dept_id = d.id
JOIN product p ON o.product_id = p.id
GROUP BY d.dept_name, u.city, u.level,
p.product_name, p.category, DATE(o.create_time);
这段SQL看起来还算正常，但真实的业务往往更夸张。字段越堆越多的原因通常有三个：第一，需求方要一张大宽表，各种维度都要能看，开发者图省事一次性全塞进GROUP BY；第二，SELECT里带了不属于分组键的字段，为了让SQL不报错就往GROUP BY里补字段；第三，把本该在应用层做的展示逻辑（比如拼接明细、格式化文案）也压到了SQL里。
字段过多的直接后果是分组粒度变得极细。五个维度字段做笛卡尔积式的组合，分组数量呈指数级增长，聚合操作的数据量也跟着膨胀，执行计划很容易走临时表加文件排序，内存扛不住就落盘，性能急剧下降。此外，在MySQL的ONLY_FULL_GROUP_BY模式下，任何SELECT中出现却没出现在GROUP BY里的非聚合列都会直接报错，字段一多维护起来也容易漏。
二、方案一：梳理业务逻辑，拆分统计口径
很多情况下，GROUP BY字段过多是因为一个SQL承担了多个不同的统计任务。比如老板既想看按部门的业绩汇总，又想看按城市和产品的分布，这本来就是两个统计口径，硬塞在一个SQL里自然字段爆炸。正确的做法是拆开：
-- 查询1：按部门统计业绩 SELECT d.dept_name, SUM(o.amount) AS total_amount FROM orders o JOIN user u ON o.user_id = u.id JOIN department d ON u.dept_id = d.id GROUP BY d.dept_name; -- 查询2：按城市和产品类目统计 SELECT u.city, p.category, COUNT(*) AS order_count FROM orders o JOIN user u ON o.user_id = u.id JOIN product p ON o.product_id = p.id GROUP BY u.city, p.category;
拆分之后每个查询的分组键都精简到位，各自走各自的索引，执行效率通常比一条大SQL高得多。最后在应用层把两个结果集按业务需要组装，或者在数据库里用JOIN合并。需要注意的是，JOIN合并时要找准关联键，避免不同粒度的数据互相放大导致统计值翻倍。
另一种简化手法是利用聚合函数的嵌套能力。有些字段其实只是“跟着带出来”的属性，并不是真正的分组维度。比如部门名称和部门ID是一一对应的，只需要按ID分组，名称可以用MAX(d.dept_name)带出来，既满足ONLY_FULL_GROUP_BY的要求，又不用把名称加进GROUP BY：
SELECT
d.dept_id,
MAX(d.dept_name) AS dept_name, -- 名称与ID一一对应，用MAX带出即可
SUM(o.amount) AS total_amount
FROM orders o
JOIN user u ON o.user_id = u.id
JOIN department d ON u.dept_id = d.id
GROUP BY d.dept_id;
这个技巧的前提是两个字段之间确实存在函数依赖关系，否则用MAX带出来的值可能不符合业务预期。判断标准很简单：如果分组键确定了，另一个字段的值也就唯一确定了，那它就没资格作为分组键。
三、方案二：用临时表分步聚合
当统计逻辑确实需要多个维度，没法拆分口径时，可以考虑分步聚合。核心思路是：先按最小粒度做一次聚合，把中间结果落到临时表，再基于临时表做二次汇总。这样每一步的GROUP BY字段都不多，执行压力被摊薄了。
-- 第一步：按最小粒度聚合，落临时表
CREATE TEMPORARY TABLE tmp_order_detail AS
SELECT
u.dept_id,
u.city,
p.category,
DATE(o.create_time) AS order_date,
SUM(o.amount) AS day_amount
FROM orders o
JOIN user u ON o.user_id = u.id
JOIN product p ON o.product_id = p.id
WHERE o.create_time >= '2024-01-01'
GROUP BY u.dept_id, u.city, p.category, DATE(o.create_time);
-- 第二步：基于中间结果做不同维度的二次汇总
SELECT dept_id, category, SUM(day_amount) AS total_amount
FROM tmp_order_detail
GROUP BY dept_id, category;
DROP TEMPORARY TABLE IF EXISTS tmp_order_detail;
临时表方案的优点很明显：中间结果集通常比原始明细表小几个数量级，二次聚合的速度非常快；而且中间表可以反复利用，多个报表口径都从它出发，避免了重复扫描大表。MySQL的TEMPORARY表是会话级别的，连接断开自动清理，不用担心残留。如果是跨会话或者定时任务场景，也可以用普通表代替，配合TRUNCATE控制生命周期。
当然临时表也有代价。一是额外的建表和写入开销，如果中间结果本身就不大，直接用子查询或CTE可能更快；二是在主从架构下，CREATE TABLE ... AS SELECT这类语句在语句级复制时可能带来一致性问题，建议改用先建表再INSERT的写法，走行级复制更稳妥。权衡的标准是：中间结果会被多次复用、或者原始表数据量巨大时，用临时表；只是一次性查询，用子查询就够了。
四、配套的索引与规范建议
无论选哪种方案，索引设计都直接影响GROUP BY的效率。理想情况是让分组列与过滤列组成联合索引，且分组列在索引中连续排列，这样数据库可以直接利用索引的有序性完成分组，避免额外的排序操作。比如经常按dept_id, city分组，那在这两列上建联合索引就是值得的。
规范层面还有三点建议：第一，SELECT列表里的每个字段要么是分组键，要么被聚合函数包裹，养成这个习惯后ONLY_FULL_GROUP_BY报错基本与你无缘；第二，明确统计口径再动手写SQL，口径不清晰的报表宁可拆成多张，也别硬凑一条大宽表；第三，对复杂统计SQL做好注释，说明每个分组维度代表的业务含义，后面接手的人不至于越改越乱。
总的来说，GROUP BY字段过多往往是业务建模问题的信号，而不是SQL语法问题。先审视统计口径是否清晰、维度是否真的必要，再决定是拆分查询还是引入临时表，绝大多数性能和限制问题都能迎刃而解。