filter子句仅postgresql 9.4+支持，mysql等主流数据库不兼容；它仅作用于单个聚合函数，不改变分组或行过滤逻辑，与case when等价但更简洁安全。
FILTER子句只在PostgreSQL 9.4+中可用，MySQL和SQL Server不支持
想用 FILTER 实现条件聚合？先确认你的数据库是不是 PostgreSQL。MySQL、SQL Server、SQLite（除非用最新编译版）、Oracle 都没有这个语法——它们要么报错 ERROR: syntax error at or near "FILTER"，要么直接忽略关键字导致逻辑错误。PostgreSQL 是目前唯一把 FILTER 作为标准聚合修饰符落地的主流数据库。
替代 WHERE 的聚合过滤：FILTER 和 CASE WHEN 的关键区别
FILTER 不是 WHERE 的别名，它只作用于单个聚合函数，不影响整行是否参与其他计算。比如你同时要算总人数和“活跃用户数”，用 FILTER 可以避免重复扫描或写冗余子查询：
SELECT COUNT(*) AS total, COUNT(*) FILTER (WHERE status = 'active') AS active_count, AVG(score) FILTER (WHERE score > 0) AS avg_positive_score FROM users;
而用 CASE WHEN 虽然等价，但更啰嗦且易出错：
-- 等价但不推荐：容易漏写 ELSE NULL，且语义不如 FILTER 清晰 COUNT(CASE WHEN status = 'active' THEN 1 END)
注意：所有 FILTER 后的条件表达式必须是布尔值，不能是字符串或数字；FILTER (WHERE x) 中的 x 不能是聚合函数（如 MAX()），否则报错 cannot use window function in FILTER clause。
嵌套聚合 + FILTER 容易触发“aggregate function calls cannot be nested”错误
你不能在 FILTER 条件里再调用聚合函数，比如下面这句会失败：
SELECT COUNT(*) FILTER (WHERE MAX(created_at) > '2023-01-01') FROM orders;
因为 MAX(created_at) 是聚合，而 FILTER 所在层级还没完成分组。正确做法是先分组再过滤，或改用子查询：
- 如果目标是“每个用户最近订单在2023年后的订单数”，得先用
GROUP BY user_id算出每人最大时间，再外层统计 - 如果只是全局判断，直接用
WHERE created_at > '2023-01-01'更合适——FILTER不是万能的 where 替代品
性能上 FILTER 比子查询轻量，但比原生 WHERE 稍慢
PostgreSQL 对 FILTER 做了优化，执行计划里通常显示为 Aggregate (filtered)，不会额外生成物化子结果集。但相比直接在 WHERE 中过滤行，它仍需对每行评估所有 FILTER 条件，尤其当条件复杂（含函数调用）时，CPU 开销会上升。简单场景下差异可忽略；高频聚合+多 FILTER 时，建议用 EXPLAIN ANALYZE 对比实际耗时。
真正容易被忽略的是：FILTER 不会改变 GROUP BY 的分组键，也不会影响 HAVING 子句的输入行集——它只改聚合函数的输入集合。这点和 WHERE 有本质区别，混用时逻辑容易错位。
