同一组数据，FILTER计数为什么不约束另一个最大值

一张分组报表里，某地显示“符合条件的记录有两条”，旁边的最大金额却来自一条不符合这个条件的记录。这样的组合不一定是数据库算错了。先看限制条件写在哪个位置：它可能只管一个计数，没有管同一行中的其他统计项。

PostgreSQL 17官方聚合教程把FILTER作为单个聚合的选项介绍。它筛选的是所附着的那个聚合函数的输入。因此，给count(*)附上FILTER条件，并不会让旁边不带该条件的max也只看相同记录。结果虽然排在一行里，各列使用的输入口径仍可能不同。

用一组假设数据说明：同一个城市有三条订单，金额分别为10、20和90。若只给计数附上“金额小于50”的FILTER，计数是2；另一项没有FILTER的最大金额仍是90。这里是在说明条件范围，没有连接数据库执行示例，也没有拿真实订单作统计。

把同样的条件移到WHERE，问题就变了。WHERE在分组与聚合之前挑选输入行。在上述假设里，金额90的行先退出共同输入，后面的计数和最大值都只能从10与20中计算。不能因为两处都写了“金额小于50”，就把查询视为同一个统计问题；条件的文字相同，作用对象可以不同。

还有一种容易被忽略的差别：假设另一个城市只有金额90的记录。使用仅作用于计数的FILTER时，这个城市仍可形成一个组，计数为0，未受该条件限制的最大值为90；如果共同输入先经WHERE排除这条记录，它便没有该行参与后续分组。由此可见，“没有符合条件的计数”和“结果中没有这个组”需要分别解释。

HAVING回答的又是后一阶段的问题：哪些已经形成的组要保留。教程明确区分了WHERE选择输入行、HAVING选择分组结果的逻辑顺序。因此，检查一张报表时，可以先写出所有统计列共同看到的行，再逐列标出各自的FILTER，最后看分组结果是否还经过HAVING筛选。这样的说明比只记录一句“查询已加条件”更清楚。

本文限定于2026年10月13日实际读取的PostgreSQL 17官方文档语义。假设订单用于解释输入范围，不是生产案例或性能测试。FILTER本身也不会替业务人员决定正确口径：究竟要展示条件内的最大值，还是用条件计数配合全组最大值，仍应由报表要回答的问题明确规定。