filter是postgresql 9.4+引入的聚合函数修饰符，用于在聚合前按条件筛选行，语法为“聚合函数 filter (where 条件)”，仅支持postgresql原生及sqlite 3.30+实验性支持。
SQL中FILTER子句的语法和基本用法
FILTER 是 PostgreSQL 9.4+ 引入的聚合函数修饰符，作用是在聚合前对行做条件筛选，类似 CASE WHEN 的简化写法，但更语义清晰、不易出错。它不能单独使用，必须跟在聚合函数后面，用括号包裹 WHERE 风格的布尔表达式。
常见错误是把它当成独立子句写在 GROUP BY 后面，或者误以为 MySQL 或 SQL Server 支持——目前仅 PostgreSQL 原生支持（SQLite 3.30+ 有实验性支持，但行为不完全一致）。
-
SELECT COUNT(*) FILTER (WHERE status = 'active') FROM orders;—— 统计 active 订单数，等价于SUM(CASE WHEN status = 'active' THEN 1 ELSE 0 END) -
FILTER中不能引用聚合别名或窗口函数，只能用原始列或表达式 - 多个
FILTER可同时出现在同一查询中，比如AVG(amount) FILTER (WHERE paid), MAX(amount) FILTER (WHERE refunded)
与CASE WHEN对比：何时该用FILTER？
功能上 FILTER 和 CASE WHEN 在聚合中效果一致，但语义和可维护性差异明显。当你需要对同一组数据做多个条件统计时，FILTER 更直观且避免重复写 CASE 分支。
例如统计不同状态的订单金额总和：SELECT SUM(total) FILTER (WHERE status = 'paid'), SUM(total) FILTER (WHERE status = 'refunded'), SUM(total) FILTER (WHERE status = 'cancelled') FROM orders;
换成 CASE 写法会冗长且易漏掉 ELSE 0 导致 NULL 干扰结果。而 FILTER 天然忽略不匹配行，聚合函数只处理符合条件的值——这点和 CASE + SUM 行为一致，但代码更干净。
- 性能上无本质差别，PostgreSQL 会将
FILTER优化为与CASE相同的执行计划 - 如果需在条件中做复杂计算（如子查询、窗口函数），仍得退回
CASE，因为FILTER不支持这些 - MySQL 用户别硬套——没有
FILTER，必须用SUM(IF(...))或CASE
FILTER在GROUP BY场景下的典型误用
容易混淆的是：把 FILTER 当成 HAVING 用，试图过滤分组后的结果。这是错的。FILTER 只影响单个聚合函数的输入行，不改变分组逻辑，也不过滤分组本身。
比如想“只显示用户数 > 10 的城市”，下面写法无效：SELECT city, COUNT(*) FILTER (WHERE age > 18) FROM users GROUP BY city HAVING COUNT(*) > 10; —— 这里 HAVING 用的是未加 FILTER 的总数，不是成年人数。
- 若要按条件后统计值过滤分组，仍需
HAVING配合对应聚合，如HAVING COUNT(*) FILTER (WHERE age > 18) > 10 -
FILTER不能用于WHERE或ORDER BY，只属于聚合函数的一部分 - 嵌套聚合（如
AVG(SUM(x) FILTER (...))）不合法，FILTER必须紧贴最外层聚合函数
兼容性与替代方案提醒
如果你的生产环境不是 PostgreSQL，或者用的是旧版（FILTER。这时候必须用 CASE WHEN 模拟，且要注意 NULL 处理。
示例（通用写法）：SELECT SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) AS paid_total FROM orders;
- 用
ELSE 0而非ELSE NULL，避免SUM结果为 NULL（除非你明确需要） - SQLite 3.30+ 支持
FILTER，但不支持复合表达式（如(a > 0 AND b 需拆成单条件） - 即使在 PostgreSQL，ORM 如 SQLAlchemy 默认不生成
FILTER，需手动构造或启用方言支持
真正要用好 FILTER，先确认数据库版本和类型，再检查聚合目标是否真的需要条件筛选——不是所有“带条件的统计”都适合它，比如涉及多表关联或动态条件时，子查询可能更可控。
