在实际业务查询里，我见过太多次这个报错：

ERROR: column "t.domainid" must appear in the GROUP BY clause or be used in an aggregate function

几乎每一个从 MySQL 转 PostgreSQL 的开发者，都会在 GROUP BY 上被这个错教育一次。报错里出现的字段名可能是 t.domainid、可能是 t.name、也可能是任何你 SELECT 出来的普通列，但本质都一样：你在分组查询里，放了一个既没参与分组、也没被聚合函数处理的字段。

这篇文章我不打算只翻译一下英文报错就完事，而是把这个错误的底层语义、最常见的三个触发场景、五种可落地的修复方案、连带报错的排查清单一次性讲透。如果你正被这个错卡住，或者想避免以后在线上被它坑，这篇可以直接照着抄。

1. 报错拆解：PostgreSQL 到底在较什么真

1.1 错误信息逐词拆开看

这句话拆开看，关键就在中间这半句：must appear in the GROUP BY clause or be used in an aggregate function。它给出了两个合法选项——你要么把这个字段加进 GROUP BY，要么用聚合函数把它“包住”。两个都不做，查询就被判定为非法。

举个例子，假设有一张用户访问日志表：

CREATE TABLE access_log ( domainid BIGINT, user_name TEXT, visit_time TIMESTAMP, visit_count INT );

如果你执行：

SELECT domainid, user_name, SUM(visit_count) AS total FROM access_log GROUP BY domainid;

PostgreSQL 会毫不犹豫地甩出那句经典报错。原因在于 user_name 这个列：它既没有出现在 GROUP BY 子句里，又不是 SUM、COUNT、MAX 这类聚合函数的参数。现在按 domainid 分组，一个分组里可能有一百行 user_name，结果集这一行的 user_name 到底该填哪一条？数据库没法替你回答。

1.2 分组查询的语义底线在哪

要理解 PostgreSQL 为什么这么“较真”，得回到分组查询的本质。GROUP BY 执行完之后，结果集里的每一行代表的是一个分组，而不是原始记录。既然是一组记录汇总成一行，出现在这行里的每个字段就必须有明确含义：要么它本身就是分组依据（GROUP BY 里的列），要么它是对组内多条记录算出来的聚合值。

如果允许一个普通列直接出现在结果里，那这个值就相当于“从组内随机挑了一条”，而“随机挑”这件事是数据库无法保证的。你今天查到的是这条，明天同样的 SQL 因为索引、并行计划、数据分布变化，可能就变成了另一条。这种不确定性在报表、对账、分页这类场景里是致命的。

这里就不得不提 MySQL 的对比。MySQL 在默认的 sql_mode（不包含 ONLY_FULL_GROUP_BY）下，是允许这种写法的，它会直接取组内第一条扫描到的记录。很多从 MySQL 迁过来的开发者，写的分组 SQL 里塞了一堆非聚合字段，在 MySQL 跑得好好的，一到 PostgreSQL 就集体报错。这不是 PostgreSQL 太死板，而是它选择了正确但严格的那条路。

注意：MySQL 只要执行SET sql_mode = 'ONLY_FULL_GROUP_BY'，也会变成和 PostgreSQL 一样严格。也就是说，MySQL 并非做不到标准行为，只是默认没开。

PostgreSQL 这种严格模式是写进 SQL 标准的。标准要求结果集语义必须无歧义，所以所有参与 SELECT 的非聚合列都必须出现在 GROUP BY 中。从 9.1 版本开始，PostgreSQL 对这块的校验就完整生效，一直延续到今天。

2. 最容易踩坑的实际场景

2.1 从 MySQL 带过来的写作习惯

我接手过好几次从其他数据库迁到 PostgreSQL 的项目，每次都能在迁移日志里看到大量「must appear in the GROUP BY」的报错。典型的老写法是这样的：

SELECT u.id, u.name, u.email, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON o.user_id = u.id GROUP BY u.id;

这段 SQL 的逻辑意图很清楚：查出每个用户的订单数，同时带上用户的基本信息。但 PostgreSQL 会告诉你 u.name、u.email 都没有被合法处理。原因还是那句话——GROUP BY 只写了 u.id，SELECT 却要了 u.name 和 u.email。

从 MySQL 过来的人会觉得这很蠢：我都按 u.id 分组了，id 唯一确定了用户，难道 name 还能不一样吗？从关系理论的角度说，这个说法其实成立，这叫“函数依赖”。PostgreSQL 16 之前不认这种推导，16 开始才增加了对主键、唯一约束的函数依赖识别（后面专门讲），但那是新版本特性，不能指望所有环境都升级。

2.2 分组后想“顺便”带个明细字段

第二种高频踩坑场景，是分组统计的同时想带出某个明细字段作展示。比如查询每个域名的访问量，同时把域名对应的负责人名字也带出来：

SELECT t.domainid, t.owner_name, COUNT(*) AS pv FROM page_views t GROUP BY t.domainid;

这段代码就是标题里那个报错的最典型翻版。owner_name 不在 GROUP BY 里，也没有被聚合，于是 PostgreSQL 直接拒绝执行。这种“分组 + 附带字段”的组合在管理后台的列表页、报表导出场景里特别常见，几乎每个写 SQL 的人都会撞上一次。

2.3 排行榜和“最新一条”查询

第三种场景更有意思——你以为自己写的不是分组查询，其实语法上已经触发了 GROUP BY 校验。比如查每个用户最新一次登录记录这种经典问题：

SELECT user_id, login_time, ip_addr FROM login_history GROUP BY user_id;

有人想当然地把GROUP BY user_id当成“按用户分组然后取最新一条”。结果 login_time 和 ip_addr 双双报错。这暴露了一个常见误解：GROUP BY 并不是“取每组里的一条记录”，而是“把每组所有记录压成一行”。取最新一条要做的是另一套语义操作，得用后面说的 DISTINCT ON 或者窗口函数。

排行榜场景也会踩：按部门统计销量的同时想把部门经理名字带出来，按商品类目统计库存的同时想把类目负责人带出来。凡是“分组 + 附属字段”的组合，十有八九都要撞上这个报错。

3. 五个可落地的解决方法

3.1 全量补列：最简单，但要小心结果变多

最直观的修复方法，就是把报错里点名的列全部塞进 GROUP BY：

SELECT t.domainid, t.owner_name, COUNT(*) AS pv FROM page_views t GROUP BY t.domainid, t.owner_name;

改写之后，语义变成了“按 domainid + owner_name 的组合分组”，每个组合对应一行。如果 owner_name 和 domainid 确实是一对一关系，行数和预期一致，查询没问题。

但如果这个字段在组内本来就有多个值，比如每个 domainid 下有多个 owner_name，分组粒度被放大，行数会变多，统计数字也会被拆散，结果可能就不是你要的。所以“全量补列”只适合字段与分组键存在稳定对应关系、或者你确实需要按多列分组的情况。

3.2 聚合函数收口：语义明确但要想清楚取哪个值

第二种做法是给这些附属字段套上聚合函数，让它们从“普通列”变成“聚合结果”：

SELECT t.domainid, MAX(t.owner_name) AS owner_name, COUNT(*) AS pv FROM page_views t GROUP BY t.domainid;

MAX(owner_name)的语义是“组内 owner_name 的最大值”，这个值完全确定，所以 PostgreSQL 不会报错。同理可以用 MIN、MAX 处理数值和字符串，用 array_agg 收集所有取值：

SELECT t.domainid, string_agg(t.owner_name, ', ') AS owner_names, array_agg(t.owner_name) AS owner_name_list, COUNT(*) AS pv FROM page_views t GROUP BY t.domainid;

如果组内只有一个值，MAX 和 MIN 都能精准还原。如果有多个值，MAX 会挑出字典序最大的那个。这时候要问自己：这个“最大”对业务有意义吗？没有意义就别硬套，改用 string_agg 把全部值列出来，或者考虑用别的方案。这一节的关键不是教你怎么骗过数据库，而是让你想清楚：这一行里，你希望这个字段以什么身份出现。

3.3 DISTINCT ON：分组内取指定记录的最佳工具

如果你面对的是“每个 X 取最新/最旧一条”的需求，DISTINCT ON 才是正解。它是 PostgreSQL 特有的语法，专门解决这类问题：

SELECT DISTINCT ON (t.domainid) t.domainid, t.owner_name, t.visit_time FROM page_views t ORDER BY t.domainid, t.visit_time DESC;

这里DISTINCT ON (t.domainid)的含义是：按 domainid 分组，在每个分组里取出按 ORDER BY 排序后的第一条记录。注意，ORDER BY 必须以 DISTINCT ON 的字段作为最左前缀，后面再跟你的排序规则。

这个写法的好处：没有 GROUP BY，也就没有“非聚合列必须分组”的问题；结果行数和分组数相同；组内哪条记录被选中完全由 ORDER BY 决定，确定性强。查每个用户最新一单、每个商品最新价格、每个域名最新访问记录，都靠它。

注意：DISTINCT ON 的 ORDER BY 如果不以 DISTINCT ON 字段开头，会直接报语法错。另外，如果想取的不是每组一条而是每组前三条，DISTINCT ON 就无能为力了，那得用窗口函数。

3.4 窗口函数：不减少行数的分组统计

有些需求需要的不是“每组一行”，而是“每一行都在旁边显示所属分组的统计值”。比如想在原始记录列表上加一列“该 domainid 的总访问量”，但不想丢掉明细行。用窗口函数：

SELECT t.domainid, t.owner_name, t.visit_time, COUNT(*) OVER (PARTITION BY t.domainid) AS domain_pv FROM page_views t;

COUNT(*) OVER (PARTITION BY ...)是窗口聚合：它不会合并行，而是对每一行计算所属分区的聚合值。因为窗口聚合的结果本身就是聚合值，所以不存在“非聚合列强制分组”的问题。

这种写法在“明细 + 汇总”同屏展示，或者计算占比（每个明细值除以总分区的聚合值）的场景非常顺手。这也是我个人比较偏爱的方案之一，因为它既不用改分组粒度，也不会丢失记录，结果集结构跟原始表完全一致。

3.5 CTE 先聚合再回表：最稳的组合拳

最后一种方法，是把查询拆成两步：先在 CTE/子查询里做聚合，得到分组粒度的小结果集，再把它 JOIN 回原表，取出需要的明细字段：

WITH domain_stats AS ( SELECT t.domainid, COUNT(*) AS pv FROM page_views t GROUP BY t.domainid ) SELECT t.domainid, t.owner_name, s.pv FROM page_views t JOIN domain_stats s ON s.domainid = t.domainid;

这个方案能精确控制每一行怎么产生：聚合查出来的只有分组和聚合值，明细字段是从原表里取的。如果 owner_name 在 domainid 内唯一，结果依旧每组一行；如果不唯一，你会看到多行明细都带着同一个统计值，这反而是更接近真实业务语义的结果。

实际优化时可以配合索引：domain_stats 只做分组统计，JOIN 时让原表通过 (domainid) 索引快速回表，多数情况下性能可控。而且这种写法对后续维护特别友好，想加字段就在外层 SELECT 加，不会影响聚合逻辑。

4. 连带报错与排查速查表

4.1 ORDER BY 和 HAVING 同样会报

很多人修好了 SELECT 列表里的列，转头又在 ORDER BY 或 HAVING 里踩同一个坑。PostgreSQL 对 ORDER BY 的校验是：ORDER BY 里出现的非聚合列，同样必须出现在 GROUP BY 中。比如：

SELECT t.domainid, COUNT(*) AS pv FROM page_views t GROUP BY t.domainid ORDER BY t.owner_name;

owner_name 没在 GROUP BY 里，这个查询照样报错。HAVING 也一样，没法在 HAVING 里直接过滤某个明细字段，除非它被聚合函数包住，或者出现在 GROUP BY 里：

-- 报错写法 SELECT t.domainid, COUNT(*) FROM page_views t GROUP BY t.domainid HAVING t.owner_name = '某同学'; -- 正确写法之一 SELECT t.domainid, COUNT(*) FROM page_views t GROUP BY t.domainid HAVING MAX(t.owner_name) = '某同学';

排查这类问题时，把 SELECT、ORDER BY、HAVING 三个位置的列全部过一遍，确认每个非聚合列要么在 GROUP BY 里，要么被聚合函数包住，基本就能消掉九成报错。

4.2 另一个常被忽略的小细节

PostgreSQL 允许在 GROUP BY 和 ORDER BY 里使用 SELECT 列表的序号，例如：

SELECT t.domainid, t.owner_name, COUNT(*) FROM page_views t GROUP BY 1, 2;

使用序号能在修改字段名时减少改动，但可读性很差。生产环境我更建议显式写列名，尤其在 GROUP BY 中，单独用数字很容易在看 SQL 时造成困惑。另外不要混用：一个查询里一会儿用序号、一会儿用列名，维护起来容易懵。

4.3 常见问题快查表

4.4 PostgreSQL 16 的主键函数依赖福利

如果你用的是 PostgreSQL 16 或更高版本，有一类场景可以松一口气：当 GROUP BY 中包含了某张表的主键（或唯一约束），这张表的其他列就可以不出现在 GROUP BY 中。因为主键能唯一决定这一行的其他字段，函数依赖成立，结果没有歧义。

回到 2.1 的例子：

-- PostgreSQL 16+ SELECT u.id, -- 主键 u.name, -- 可以不出现在 GROUP BY 里 u.email, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON o.user_id = u.id GROUP BY u.id;

在 16 之前，这个查询必须把 u.name、u.email 也加进 GROUP BY，或者用 MAX 包住。16 之后，因为 GROUP BY 里有主键 u.id，其他列自动满足函数依赖。这个特性在处理“按主表分组 + 带主表附属字段 + 统计子表”的典型场景时非常好用。不过要注意，函数依赖目前识别的是主键和唯一约束，不保证能推导出业务上的任意一对一关系，所以别把所有类似需求都赌在这个特性上。

5. 我的实操心得与建议

5.1 迁移项目中最值得做的三件事

如果你正在做数据库迁移，或者刚切换过来，我建议提前做三件事。

第一，给团队整理一份“分组查询常见写法对照”，把 MySQL 老写法、PostgreSQL 正确写法、报错原因三列并排写清楚。我见过太多人在同一个坑里反复踩，一份对照表能省下大量沟通成本。

第二，在开发库上尽量用新版 PostgreSQL。16 的函数依赖特性确实能减少一批报错，而且新版对分区表、并行查询的支持也更成熟。如果项目有条件升级，早点升级比晚点升级成本低。

第三，写完 SQL 养成自查习惯：SELECT、ORDER BY、HAVING 里的每一个非聚合列，逐一确认它要么在 GROUP BY 里，要么被聚合函数包住。这个习惯坚持一个月，基本就再也不会看到这条报错了。

5.2 几个容易继续踩的雷

再分享几个我在实际项目中踩过的相关细节。

一个是 DISTINCT ON 和 ORDER BY 的顺序问题：DISTINCT ON 括号里的列必须匹配 ORDER BY 的最左侧列，顺序错了直接报语法错，而且往往先看到一条无关的语法错误信息，容易绕弯子。这时候把 ORDER BY 前几列改成和 DISTINCT ON 一致就好。

另一个是聚合函数的选择要配合业务含义。MAX 一个字符串字段从语法上没问题，但如果你用它来“随便取一个值”，业务上就是埋雷。我通常建议这种情况要么用 string_agg 把所有值串出来，要么回到数据模型去确认这个字段是否真的和分组键一一对应。如果确实一一对应，直接全量补列更简单直观。

再一个是性能层面：能在一个 SQL 里用窗口函数解决的，尽量不要拆成两个查询在应用层做二次处理。反过来，如果某个分组统计在明细表上要扫全表，而明细表又特别大，先聚合再回表、配合合适的索引，往往比窗口函数更快。没有银弹，拿数据量说话。

5.3 最后再分享一个排查技巧

当报错信息里有多个字段一起出现时，比如同时报 t.owner_name、t.visit_time，别着急把报错里点名到的所有字段全塞进 GROUP BY。先停下来想一下：这些字段在组内是唯一对应的吗？如果是，塞进 GROUP BY 没问题；如果不是，你的查询结果行数会悄悄变多。我在实际测试中踩过一次——顺手把三个字段都加进去，结果报表里的汇总数字翻了快一倍，排查了很久才发现是 GROUP BY 粒度被改写了。

这种情况下更稳的做法，是先聚合得到每组的汇总值，再 JOIN 回原表取明细字段，让结果行数完全在掌控之中。这个套路我后来几乎用成了标准答案：凡是“分组统计 + 附带明细字段”的组合，默认先想清楚行数预期，再决定是补列、DISTINCT ON 还是 CTE 回表，基本不会再被 PostgreSQL 这条报错绊住。