filter子句仅postgresql 9.4+原生支持，mysql、sql server等不兼容；必须写作“agg() filter (where cond)”，括号不可省，用于行级条件聚合，语义清晰且优于case when。
FILTER子句只在PostgreSQL 9.4+支持，MySQL和SQL Server不能用
想用 FILTER 做条件聚合？先确认数据库是不是 PostgreSQL。MySQL、SQL Server、SQLite、Oracle 都不支持这个语法——它们要么报错 syntax error at or near "FILTER"，要么直接忽略。只有 PostgreSQL 从 9.4 版本起原生支持 FILTER，它是标准 SQL:2003 的扩展实现，专为“在聚合函数内加条件”而生，比写多个 CASE WHEN 更简洁、语义更清晰。
常见误操作包括：把 PostgreSQL 的写法直接复制到 DBeaver 连 MySQL 时执行，或在阿里云 RDS MySQL 实例里尝试，结果卡在报错上。别浪费时间调试语法，先查版本：SELECT version();，看到包含 PostgreSQL 9.4 或更高才继续。
怎么写一个带FILTER的COUNT或SUM统计
FILTER 必须跟在聚合函数后面、括号外，用 WHERE 引导条件表达式。它不是独立子句，不能单独出现，也不能嵌套在 WHERE 或 HAVING 里。
-
COUNT(*) FILTER (WHERE status = 'paid')统计已支付订单数，等价于SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END)，但更直观 -
SUM(amount) FILTER (WHERE created_at >= '2024-01-01')只对今年订单求和，amount字段本身无需NOT NULL检查，FILTER自动跳过不满足条件的行 - 多个聚合可共用同一组数据但不同条件：比如同时算「总订单数」「已支付数」「退款数」，每个都挂自己的
FILTER，不用反复JOIN或子查询
注意：条件里不能引用外部查询的列（除非是相关子查询，但极少见），所有字段必须来自当前作用域的 FROM 表。
FILTER和CASE WHEN性能有差别吗
在 PostgreSQL 中，FILTER 和等效的 CASE WHEN 执行计划几乎一致，优化器会生成相同的 Aggregate 节点。但有两点实际差异：
-
FILTER更轻量：不产生额外的表达式计算开销，尤其当条件复杂（含函数或子查询）时，CASE WHEN可能被多次求值，而FILTER是单次判定 - 可读性优势明显：五个条件聚合写成五段
COUNT(*) FILTER (WHERE ...)比五段SUM(CASE WHEN ... THEN 1 ELSE 0 END)少一半字符，且意图一目了然 - 空值处理更自然：比如
AVG(score) FILTER (WHERE score > 0)自动排除score IS NULL和score 的行；而用 <code>CASE时容易漏掉ELSE NULL导致平均值偏差
GROUP BY里混用FILTER和普通聚合要小心NULL逻辑
当一组数据中没有任何行满足 FILTER 条件时，对应聚合结果是 NULL（不是 0）。例如：COUNT(*) FILTER (WHERE country = 'ZZZ') 在某分组中没匹配到任何记录，结果就是 NULL。这和 COUNT(*) 永远返回非负整数不同。
容易踩的坑：
- 前端展示时直接渲染
NULL成空字符串或undefined，造成统计数字“消失”，应显式用COALESCE(count_col, 0) - 在
HAVING中过滤这类聚合结果，比如HAVING COUNT(*) FILTER (WHERE paid) > 0，没问题；但写成HAVING COUNT(*) FILTER (WHERE paid) != 0会漏掉NULL情况，因为NULL != 0返回NULL（即 false） - 和
ORDER BY一起用时，NULLS LAST要手动声明，否则默认可能排最前，干扰排序逻辑
真正麻烦的不是语法，而是团队里有人不知道 FILTER 返回 NULL，还在报表 SQL 里裸用，结果运营天天问“为什么这个渠道订单数显示为空”。
