PostgreSQL 用 WHERE 列 = MAX(列) 筛选时报聚合函数错误

统计最新期次的报名人数时，如果把条件写成 WHERE period_id = MAX(period_id)，PostgreSQL 会报 aggregate functions are not allowed in WHERE。查询还没得到统计结果，就在校验 SQL 时停下了。

这类查询通常想做两件事：先找到最大的期次编号，再从该期次的报名记录中计数。把求最大值和行筛选直接写在同一层 WHERE 中，无法表达这个先后关系。将最大值放进独立子查询，外层 WHERE 就能用它筛选记录。

以下适用于 PostgreSQL 中“按某个集合的最大值筛选记录”的查询。示例把最大期次编号当作目标期次；实际业务只有在编号大小确实代表先后顺序时，才能把它叫作最新期次。

把最大值放进独立查询

假设 periods 保存期次，registrations 保存报名记录，period_id 关联期次编号。下面的写法会触发错误：

SELECT COUNT(*) AS accepted_count
FROM registrations AS r
WHERE r.status = 'accepted'
  AND r.period_id = MAX(r.period_id);

WHERE 决定哪些输入行参与后面的聚合，而同一层的 MAX 又要依赖这些输入行计算结果。PostgreSQL 不允许把这一层聚合直接放在 WHERE 条件中。

如果目标是“期次表中编号最大的期次”，可以这样写：

SELECT
    COUNT(CASE WHEN r.category = 'A' THEN 1 END) AS category_a_count,
    COUNT(CASE WHEN r.category = 'B' THEN 1 END) AS category_b_count
FROM registrations AS r
WHERE r.status = 'accepted'
  AND r.period_id = (
      SELECT MAX(p.id)
      FROM periods AS p
  );

内层 MAX 针对 periods AS p 的记录计算，返回一个最大编号；外层只保留该编号下已录取的报名记录。这里子查询中的 p.id 来自子查询自己的 FROM，避免误把外层列写进聚合参数，改变聚合所属的查询层级。

每个 CASE 在类别匹配时返回 1，否则返回 NULL。COUNT 只统计非 NULL 表达式，因此两个计数分别对应 A、B 类。筛选范围里没有报名记录时，两项 COUNT 都是 0。

这种写法保留目标期次下的所有匹配行。直接给报名查询加 ORDER BY period_id DESC LIMIT 1 只会选出一行，不能替代“找到编号后统计该编号的全部记录”。

先确定最大值要从哪里取

下面两种需求看似接近，但结果可能不同：

最新建好的期次：从期次表求最大编号，然后筛选该期次的报名记录。即使该期次尚无录取记录，也应得到 0。
有录取记录的最大期次：只在已录取的报名记录中求最大编号。最新建好的期次如果没人录取，查询会选中更早的期次。

第二种需求对应的 SQL 是：

SELECT COUNT(*) AS accepted_count
FROM registrations AS r
WHERE r.status = 'accepted'
  AND r.period_id = (
      SELECT MAX(r2.period_id)
      FROM registrations AS r2
      WHERE r2.status = 'accepted'
  );

内层的状态条件改变了最大值的候选集合。外层条件仍然需要保留，否则选中期次后，该期次下未录取的记录也可能被计数。实际查询若还有租户、地区或业务类型限制，要逐项确认这些限制属于“选择期次的范围”，还是只属于“统计报名的范围”。

如果“最新”按日期判断，应该围绕真实的日期字段定义规则，不能默认较大的 ID 一定更新。日期相同时要保留所有并列记录，还是按另一个唯一字段选定一期，也应先确定。修复语法错误并不会替你决定这些业务规则。

直接改成 HAVING 仍可能不对

HAVING 用于筛选聚合后的组，例如只返回报名数超过 10 的期次：

SELECT r.period_id, COUNT(*) AS accepted_count
FROM registrations AS r
WHERE r.status = 'accepted'
GROUP BY r.period_id
HAVING COUNT(*) > 10;

但把出错条件原样挪过去，不会自动选出最大期次：

SELECT COUNT(*)
FROM registrations AS r
HAVING r.period_id = MAX(r.period_id);

这条查询把所有输入当作一个聚合组，条件里的普通列 r.period_id 没有分组，也没有放在聚合函数中，会遇到分组规则错误。

如果再补上 GROUP BY r.period_id，每组的期次编号本来就相同；对于非 NULL 编号，每组都会满足“本组编号等于本组最大编号”，还是没有与其他期次比较。要筛出全局最大期次，前面的独立子查询更符合需求。只有真正要按每组聚合结果筛组时，才使用 HAVING。

用小数据核对筛选范围和计数

可以在本机测试连接中运行下面的只读例子。VALUES 临时构造两组输入，不会创建持久表，也不需要修改生产数据。

WITH periods(id) AS (
    VALUES (10), (11), (12)
), registrations(period_id, category, status) AS (
    VALUES
        (11, 'A', 'accepted'),
        (12, 'A', 'accepted'),
        (12, 'A', 'pending'),
        (12, 'B', 'accepted')
)
SELECT
    COUNT(CASE WHEN r.category = 'A' THEN 1 END) AS category_a_count,
    COUNT(CASE WHEN r.category = 'B' THEN 1 END) AS category_b_count
FROM registrations AS r
WHERE r.status = 'accepted'
  AND r.period_id = (SELECT MAX(p.id) FROM periods AS p);

按这组数据推算，结果应为 A 类 1、B 类 1：期次 11 被排除，期次 12 中的 pending 记录也被排除。这是示例的预期结果，不是实际环境的验收结果。

再把期次列表改成 VALUES (10), (11), (12), (13)，保留报名数据不变。按“期次表中最大编号”的规则，两项计数应变成 0。这个变化能检验查询是否偷偷退回了“有报名记录的最大期次”。

还要覆盖空集合和 NULL：MAX 忽略 NULL，没有可聚合的非 NULL 值时返回 NULL。普通的等号比较不会让某一行满足“编号等于 NULL”，所以外层筛选不到记录；没有 GROUP BY 的 COUNT 仍返回一行计数 0。不要为了让查询有结果而随意用一个编号替换 NULL，这会把“没有目标期次”改成另一个业务含义。

替换查询前保留原 SQL

在实际表上，先只读查看候选最大编号，再核对该编号下有哪些记录、哪些记录符合状态及类别条件。确认取值范围后，再检查计数，而不只看报错是否消失。

保留原 SQL 和参数，先在测试环境验证典型数据与空结果。上线后若发现期次选择不符，应回退查询版本并重新确认筛选范围；这个修复不涉及删表、清空数据或重建数据库。

数据量较大时，可以用普通 EXPLAIN 查看候选查询的执行计划，再结合现有索引判断是否需要优化。不要把 EXPLAIN ANALYZE 当成单纯打印计划：它会实际执行查询。消除聚合位置错误只是让 SQL 合法，是否选对期次、是否算对人数以及执行代价，都需要分别核对。