在关系型数据库的统计查询里，聚合函数遇到空值时的行为经常让计算结果偏离业务预期。以SUM和AVG为例，标准SQL规定聚合函数会忽略NULL输入，但很多初学者误以为NULL参与运算会变成0，从而低估了平均值或错算了占比。当一张订单表中部分记录的金额字段由于漏填而为NULL，直接对全表求和虽然不会把NULL当0加进去，但在按状态分组统计有效订单额时，如果不用手段剔除无效行，就会把空洞数据混入分母，造成报表失真。FILTER子句的出现，正是为了让聚合过程可以按行级条件做精确裁剪，而不必把过滤逻辑揉进函数内部。
空值在聚合函数中的默认行为与新痛点
先理清标准SQL对NULL的约定：COUNT(*)统计所有行，COUNT(列名)只统计非NULL值；SUM、AVG、MIN、MAX都会跳过NULL。这初看合理，但业务常需要同时知道有效数据汇总与缺失数据条数。比如运营想看「已支付订单的总额」和「未填金额订单数」，若用WHERE先过滤，就只能跑两条语句；若把NULL行也放进聚合，AVG(金额)的分母会变小，数值被抬高，失去参考意义。
旧方案是在聚合里写CASE WHEN，像SUM(CASE WHEN status='paid' THEN amount END)。这种写法把条件判断塞进函数，聚合函数外再套一层，可读性随统计维度增加断崖下跌。更麻烦的是，当要对同一列做多种条件统计，比如分别算已支付、已退款、待付款的金额，就得写三个CASE WHEN，SQL长度翻倍，后续接手的人很难一眼看清每个数字的含义。
此时FILTER子句提供了一种声明式语法：聚合函数后接FILTER (WHERE 条件)，数据库只把满足条件的行送进聚合，其余行在聚合前就被丢弃，逻辑和WHERE相似但作用范围仅限该聚合。下面用PostgreSQL语法展示基础用法，你能直观看到每个指标独立挂条件，不再嵌套CASE。
SELECT COUNT(*) FILTER (WHERE status = 'paid') AS paid_orders, SUM(amount) FILTER (WHERE status = 'paid') AS paid_amount, COUNT(*) FILTER (WHERE amount IS NULL) AS null_amount_orders FROM orders;
FILTER子句语法详解与多场景代码示例
FILTER子句的位置紧跟聚合函数及其参数之后，格式为聚合函数(表达式) FILTER (WHERE 布尔表达式)。它不仅能用于SUM、COUNT，也支持AVG、MAX等。关键点在于FILTER里的条件可以使用任何行级字段，甚至关联子查询，但不可引用聚合结果本身，因为过滤发生在聚合前。下面的例子演示在同一SELECT中完成多维度日活统计：统计每天访问数、其中手机端访问数、以及停留超过10分钟的用户数。
对比传统CASE写法，FILTER让每个指标语义独立。我们在报表查询里经常要输出几十列不同维度的汇总，用CASE会导致括号嵌套五层以上，而FILTER保持扁平结构。以下代码同时统计不同渠道的转化，并列出缺失渠道标记的会话数，帮助数据团队快速定位埋点漏洞。
SELECT DATE(visit_time) AS day, COUNT(*) FILTER (WHERE channel = 'web') AS web_visits, COUNT(*) FILTER (WHERE channel = 'app') AS app_visits, COUNT(*) FILTER (WHERE channel IS NULL) AS missing_channel, AVG(duration) FILTER (WHERE duration > 600) AS deep_user_avg FROM user_session GROUP BY DATE(visit_time);
在窗口函数里FILTER同样有效。比如想给每个用户打标签：累计已支付金额，但只算今年以来的订单。可以把FILTER放在SUM OVER里，避免先过滤再join原表。这种写法在大型表上减少了中间结果集，执行计划往往更优。下面示例为每个用户在全量订单上开窗口，但聚合时仅纳入2023年以后的记录，旧订单直接被FILTER排除在求和之外。
SELECT
user_id,
SUM(amount) FILTER (WHERE order_date >= '2023-01-01')
OVER (PARTITION BY user_id) AS recent_paid
FROM orders;
与CASE WHEN及WHERE的对比和兼容方案
从执行效率看，多数支持FILTER的数据库（如PostgreSQL、SQLite）会把它优化成和CASE WHEN类似的底层算子，但查询优化器更容易从FILTER的扁平结构推导出索引使用策略。WHERE是分组前全局过滤，会直接减少参与聚合的行数，但不能在同一查询里保留被过滤掉的NULL行做其他统计；CASE WHEN能保留行但增加函数内分支；FILTER在语义上介于两者之间，既保留行又让聚合各取所需。当数据库不支持FILTER（如MySQL旧版本），可用CASE模拟，但建议封装成视图以维持可读。
兼容性方面，MySQL 8.0仍不支持FILTER，可用SUM(CASE WHEN cond THEN expr ELSE 0 END)替代，但注意ELSE NULL与ELSE 0对COUNT的区别：COUNT只关心非NULL，所以CASE里不命中的行应返回NULL而非0，否则会虚增计数。下面的兼容写法在MySQL中实现与上述FILTER相同的已支付订单数统计，请留意ELSE NULL的写法。
SELECT COUNT(CASE WHEN status = 'paid' THEN 1 ELSE NULL END) AS paid_orders, SUM(CASE WHEN status = 'paid' THEN amount ELSE NULL END) AS paid_amount FROM orders;
最后给出选型建议：若团队底座是PostgreSQL或SQLite，优先用FILTER提升可维护性；若需跨库通用，封装一个SQL生成层，根据方言自动切换FILTER与CASE。无论哪种方式，核心原则是把空值过滤显式化，不让聚合函数的默认忽略行为悄悄扭曲指标。在报表系统中，还应给每个含FILTER的字段加注释，说明其统计口径，避免后人误读数字背后的NULL含义。