先判断你是否真的需要 QUERY GROUP BY
搜索这个报错的人里，有相当一部分其实根本不应该用 QUERY。如果你的场景符合以下任意一条，建议直接切换到 SUMIFS：
- 需要引用其他工作表的参数单元格（如从"假设"表读取日期区间）
- 数据量超过1万行，对重算速度有要求
- 需要跨多张工作表汇总数据
以季度经营分析报告为例，日期区间从"参数"工作表的 $B$3:$B$4 读取，营收数据来自"损益表"工作表的 C 列：
SUMIFS 写法（推荐此场景）：
=SUMIFS(
'损益表'!C:C,
'损益表'!B:B, ">=" & 参数!$B$3,
'损益表'!B:B, "<=" & 参数!$B$4,
'损益表'!D:D, 汇总!$A2
)
QUERY 等效写法（不推荐用于此场景）：
=QUERY(
'损益表'!B:D,
"SELECT D, SUM(C) WHERE B >= date '"
& TEXT(参数!$B$3, "yyyy-MM-dd") & "'"
& " AND B <= date '" & TEXT(参数!$B$4, "yyyy-MM-dd") & "'"
& " GROUP BY D",
1
)
QUERY 无法在查询字符串内部直接引用 参数!$B$3，必须先用 TEXT() 将日期值转换为 yyyy-MM-dd 格式的字符串再拼接进去。日期格式一旦不符合要求，报出来的错误信息往往与分组语法完全无关，让人摸不着头脑。SUMIFS 则天然支持单元格引用，无需任何转换。
以下是两者的完整对比：
| 场景 | QUERY GROUP BY | SUMIFS / SUMPRODUCT |
|---|---|---|
| 单表聚合 | 语法简洁，类 SQL 风格 | 写法相对冗长 |
| 跨表引用 | 原生不支持 | 原生支持，稳定可靠 |
| 引用参数表中的动态日期 | 需要字符串拼接，日期格式易出错 | ">=" & 参数!$B$3 直接引用 |
| 多条件筛选 | WHERE 子句 | SUMIFS 堆叠条件 |
| 数据量超过1万行 | 重算速度较慢 | 速度更快 |
| 维度值集合未知 | 自动返回所有行 | 需要硬编码条件 |
| 典型报错 | cannot group without agg | 范围有误时报 #VALUE! |
关于性能：Google Sheets QUERY 函数官方文档 明确指出，QUERY 函数在每次工作表重算时都会重新执行完整的查询解析，在数据量较大的场景下，这一开销会随行数增加而显著上升。官方建议在处理大型数据集时，优先考虑使用原生数组公式（如 SUMIFS/SUMPRODUCT）以获得更好的性能。
快速修复：三步定位问题列
如果确认需要用 QUERY GROUP BY，按以下步骤逐列检查 SELECT 子句：
=QUERY('营收'!A:E, "SELECT B, C, SUM(D) GROUP BY B", 1)
此公式会报错，因为 C 列出现在 SELECT 中，但既未加入 GROUP BY，也未被聚合。两种修复方式，选哪种取决于业务需求：
方案一--保留 SKU 维度（区域×SKU 交叉分析）：
=QUERY('营收'!A:E, "SELECT B, C, SUM(D) GROUP BY B, C", 1)
方案二--去掉 SKU（仅保留区域级汇总）：
=QUERY('营收'!A:E, "SELECT B, SUM(D) GROUP BY B", 1)
审查规则只有一条：SELECT 中的每一列，要么出现在 GROUP BY 中，要么被聚合函数包裹。Google Visualization API 查询语言文档 对此有明确规定："使用 GROUP BY 时，SELECT 子句中的每一列，要么出现在 GROUP BY 子句中，要么使用聚合函数。"没有例外。
以下是一个涵盖二季度实际值的完整正确写法：
=QUERY(
'营收'!A:F,
"SELECT B, SUM(D), SUM(E), SUM(D)-SUM(E)
WHERE A >= date '2026-04-01' AND A <= date '2026-06-30'
GROUP BY B
LABEL SUM(D) '营收', SUM(E) '成本', SUM(D)-SUM(E) '毛利润'",
1
)
SUM(D)-SUM(E) 合法，因为两个组成部分均已聚合，每个分组只产生一个计算结果；SUM(D)/D 非法，因为分母 D 未聚合。这条规则适用于表达式中的每一项，不只是单独出现的列引用。
QUERY GROUP BY 真正适用的场景
当你事先不知道维度的全部取值时，QUERY 才真正发挥优势。假设当前活跃 SKU 共有14个，需要按毛利率降序排列分析各 SKU 贡献（目标毛利率38.5%，当前综合毛利率34.1%）：
=QUERY(
'销售'!A:G,
"SELECT C, SUM(D), SUM(E), (SUM(D)-SUM(E))/SUM(D)
GROUP BY C
ORDER BY (SUM(D)-SUM(E))/SUM(D) DESC
LABEL C 'SKU', SUM(D) '营收', SUM(E) '成本'",
1
)
(SUM(D)-SUM(E))/SUM(D) 不会触发分组报错，因为每个组成部分都已聚合，每个分组只输出一个值。若改用 SUMIFS，则需要为每个 SKU 单独硬编码一行；一旦数据中新增 SKU，表格立即失效。这才是 QUERY 真正值钱的地方。
容易被忽略的边界情况
COUNT 的写法： COUNT(D) 统计 D 列中的非空值数量；COUNT() 不带参数在 Google 的实现中属于非法语法。截至2026年6月，这种错误有时以 cannot group without agg 的形式出现，而非更明确的提示，容易浪费调试时间。如果分组逻辑看上去没有问题却仍然报错，请检查 COUNT 的写法。
LABEL 子句的干扰： LABEL 本身不会引发分组报错，但如果 SELECT 中已存在问题列，错误信息有时会因 LABEL 的存在而产生偏移，看起来像是标签写法有误。调试时应优先审查 SELECT 和 GROUP BY，再去检查 LABEL。
ModelMonkey 能够在公式写入工作表之前捕获这类 QUERY 报错，并在侧边栏直接给出修正后的公式--尤其适合深陷多表嵌套模型、单凭报错信息无法定位问题列的场景。
常见问题
Q：cannot group without agg 报错的最常见原因是什么？
SELECT 子句中有一列既没有出现在 GROUP BY 中，也没有被聚合函数包裹。逐列检查 SELECT，确认每一列都满足"维度列进 GROUP BY，度量列套聚合函数"这个规则即可定位问题列。
Q：QUERY 公式里能不能直接引用其他工作表的单元格作为筛选条件？
不能直接引用。QUERY 的查询字符串只接受字面量，无法识别单元格引用。日期条件需要用 TEXT() 转换后拼接进字符串，格式必须严格为 yyyy-MM-dd。如果需要频繁引用参数表中的动态值，SUMIFS 是更稳健的选择，且不会产生与真实错误无关的误导性报错。
Q：SUM(D)-SUM(E) 在 QUERY 中合法，SUM(D)/D 为什么不合法？
判断标准是表达式中每一项是否都已聚合。SUM(D)-SUM(E) 的两个组成部分都是聚合结果，每个分组只产生一个值，合法。SUM(D)/D 的分母 D 是原始列，每个分组包含多行 D 值，无法与分子的单个 SUM 结果对应，非法。这条规则适用于任意复合表达式，不只是单列引用。
Q：数据量多大时应该放弃 QUERY GROUP BY，改用 SUMIFS？
Google Sheets 官方文档建议在处理大型数据集时优先使用原生数组公式。根据实际使用经验，数据量超过1万行后，QUERY 在工作表每次重算时的延迟会变得明显。如果工作表包含大量联动公式且数据持续增长，建议提前切换到 SUMIFS，或将预处理逻辑移至 Apps Script。
小结
cannot group without agg 报错的修复逻辑很简单：SELECT 中每一列要么进 GROUP BY，要么套聚合函数。但更值得关注的是选型判断：如果需要引用参数表中的动态日期、跨多张工作表汇总数据，或处理超过1万行的数据集，SUMIFS 能处理 QUERY 力所不及的场景，且不会产生与真实错误无关的误导性报错。只有当维度值集合未知、无法提前硬编码时，QUERY 的 GROUP BY 才是真正更简洁的选择。