在SQL中处理条件聚合时，FILTER子句算得上是PostgreSQL独家的语法糖——它能让聚合函数（比如count()、sum()）只针对满足条件的行进行计算，而不必嵌套CASE WHEN。但话说回来，这个语法虽然简洁，限制也不少：它必须跟在聚合或窗口函数后面，不能独立存在；目前只有PostgreSQL 9.4+原生支持，MySQL和SQL Server完全不认，SQLite从3.30.0才有限支持（而且窗口场景下不能用）。所以，第一步就是要确认你的数据库是哪个版本。
FILTER子句必须搭配聚合函数或窗口函数使用
单独写FILTER会报错：syntax error at or near "FILTER"。这不是独立语法，而是PostgreSQL特有的修饰符，只能跟在聚合函数（如count()、sum()）或窗口函数（如sum() OVER (...)）后面。常见错误翻来覆去就那么几种：
FILTER必须写在括号内，紧贴函数名后，比如count(*) FILTER (WHERE status = 'active')。- 不能和
DISTINCT混用，例如COUNT(DISTINCT x) FILTER (...)是非法的。 - 条件表达式里不能引用窗口函数的排序字段（比如
ORDER BY中的列），否则可能触发window function calls cannot be directly nested错误。
在窗口函数中正确写法：FILTER放在函数内部，不是OVER子句里
FILTER修饰的是窗口函数内部的聚合行为，而不是整个窗口定义。它必须出现在函数调用的括号内，而不是OVER后面的括号里。很多人一开始会搞反：
错误写法：sum(amount) OVER (PARTITION BY dept) FILTER (WHERE amount > 100)——FILTER挂在了OVER外面，语法非法。
正确写法：sum(amount) FILTER (WHERE amount > 100) OVER (PARTITION BY dept ORDER BY date)
- 每个窗口函数只能有一个
FILTER子句，不能叠加多个。 - 可以和
ORDER BY共存，但FILTER不影响窗口帧（frame）范围；它只决定哪些行参与这次聚合计算。 - 如果需要按条件动态调整帧范围，得用
ROWS BETWEEN ... AND ...，而不是靠FILTER。
替代方案：FILTER vs CASE WHEN的性能与语义差异
看起来sum(x) FILTER (WHERE cond)和sum(CASE WHEN cond THEN x ELSE 0 END)效果差不多，但语义其实不同：前者跳过不满足条件的行，后者把不满足的行当作0参与计算。这对a vg()、count()等函数影响很大。
举个例子：count(*) FILTER (WHERE status = 'paid')统计付费订单数；而count(CASE WHEN status = 'paid' THEN 1 ELSE 0 END)会返回总行数——因为0也是非NULL值，count(0)会计入。所以对于count，必须写成count(CASE WHEN cond THEN 1 END)（省略ELSE，返回NULL，不计数）。
- 对于
a vg()：a vg(score) FILTER (WHERE score IS NOT NULL)和a vg(CASE WHEN score IS NOT NULL THEN score END)结果一致，但后者更啰嗦。 - 性能上，
FILTER通常略快，因为它跳过求值；CASE则需为每行计算分支。 - 可读性上，
FILTER更贴近自然语言意图，尤其在多条件组合时（如FILTER (WHERE a > 0 AND b IN ('x','y'))）。
容易忽略的NULL处理细节
FILTER条件表达式结果为FALSE或NULL时，该行被排除。这一点和WHERE一致，但容易在布尔逻辑上踩坑。
比如字段discount允许为NULL，想统计有折扣的订单数量：count(*) FILTER (WHERE discount > 0)——这会漏掉discount IS NULL和discount = 0的行，符合预期；但若写成count(*) FILTER (WHERE discount)就非法，因为discount是数值型，不能直接当布尔用。
- 安全写法始终显式比较：
WHERE discount IS NOT NULL AND discount > 0。 FILTER不改变窗口分区逻辑，它只筛行；所以sum(x) FILTER (...) OVER (PARTITION BY y)的分区仍按所有行划分，只是聚合时跳过部分。- 调试时可在SELECT中并列写出带/不带
FILTER的列，对比结果，快速定位过滤逻辑是否符合业务预期。
实际用起来最麻烦的不是语法，而是想清楚“我要过滤的是原始数据行，还是聚合后的中间结果”——FILTER只作用于函数输入行，一旦写进窗口函数，就得同步检查PARTITION BY和ORDER BY是否引入了意料外的分组或排序依赖。这才是容易翻车的地方。
