能，FILTER子句可替代CASE WHEN实现条件聚合，语法更简洁、可读性更强，且数据库更易优化；它必须紧跟聚合函数后并用括号包裹布尔表达式，仅适用于聚合函数，不支持窗口函数或外部列引用。
FILTER子句能替代CASE WHEN做条件聚合吗？
能，而且更简洁、可读性更强。PostgreSQL 9.4 引入 FILTER 后，它就成为标准的条件聚合语法，比写 CASE WHEN ... THEN value ELSE NULL END 再套 SUM() 或 COUNT() 更直接——数据库引擎也更容易优化。
常见误用是把它当成 WHERE 的替身：比如写 COUNT(*) FILTER (WHERE status = 'active') 是对的，但写 COUNT(*) FILTER WHERE status = 'active'（漏括号）会报错 syntax error at or near "WHERE"。
-
FILTER必须跟在聚合函数后面，且必须用括号包裹布尔表达式 - 只支持聚合函数，不能用于普通列或窗口函数的
OVER子句中 - 表达式里不能引用外部查询的列（除非该列在
GROUP BY中）
多个FILTER怎么同时用在一个SELECT里？
可以并列写，每个聚合函数独立带自己的 FILTER，互不影响。这是它比嵌套子查询或 CTE 更轻量的关键。
例如统计不同状态的订单数和金额：
SELECT COUNT(*) FILTER (WHERE status = 'paid') AS paid_count, SUM(amount) FILTER (WHERE status = 'paid') AS paid_sum, COUNT(*) FILTER (WHERE status = 'refunded') AS refunded_count, SUM(amount) FILTER (WHERE status = 'refunded') AS refunded_sum FROM orders;
注意：不要试图用一个 FILTER 覆盖多个聚合，比如 SUM(amount), COUNT(*) FILTER (WHERE ...) 是合法的，但 SUM(amount) FILTER (WHERE ...), COUNT(*) 里后者没 FILTER 就是全量统计——这点容易混淆，尤其从子查询迁移过来时。
和HAVING一起用时FILTER的位置很关键
FILTER 属于聚合函数的一部分，所以它在逻辑上先于 HAVING 执行。也就是说，HAVING 看到的是已经按 FILTER 计算完的结果。
比如只保留“已支付订单数超过10的用户”：
SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) FILTER (WHERE status = 'paid') > 10;
错误写法是把条件挪到 WHERE 里：WHERE status = 'paid' HAVING COUNT(*) > 10 —— 这会过滤掉所有非 paid 行，导致无法统计同一用户下的其他状态订单，语义完全不同。
-
WHERE过滤行，FILTER过滤聚合输入，HAVING过滤分组结果 - 三者顺序不可互换，调试时建议先查
GROUP BY结果不加HAVING，确认FILTER输出符合预期
性能上FILTER比子查询快多少？
没有固定倍数，但通常快 20%–50%，尤其在大表 + 多个条件聚合时。因为 FILTER 允许单次扫描完成多个条件统计，而等价的 CASE WHEN 子查询或 CTE 往往触发多次 Seq Scan 或 Materialize。
执行计划里看两个关键点：
- 是否出现
Aggregate节点下直接带Filter: ...（说明下推生效） - 对比
Buffers: shared hit=xxx数值，FILTER版本通常更低 - 避免在
FILTER表达式里调用 volatile 函数（如now()），否则可能破坏优化器估算
真正难处理的是跨时间窗口的条件聚合（比如“过去7天内首次下单用户数”），这时 FILTER 仍可用，但需要配合 ROW_NUMBER() 或 LATERAL，已经超出单条 FILTER 的能力范围了。
