FILTER 不是自动加速器，而是降低逻辑复杂度、减少错误风险的语法机制；它省去每行分支判断开销，但需正确书写且依赖外层过滤与索引配合，否则可能引发解析失败或统计失真。
FILTER 子句本身不直接提升执行速度，但它能显著减少逻辑复杂度和错误风险，从而让优化器更容易生成高效执行计划——盲目套用反而可能因误用触发全表扫描或解析失败。
为什么 FILTER 不等于“自动加速”
FILTER 不是索引或并行提示，它只是语法糖背后的语义机制。PostgreSQL 优化器在看到 sum(amount) FILTER (WHERE status = 'paid') 时，仍需扫描所有行（除非外层 WHERE 已过滤），但相比 sum(CASE WHEN status = 'paid' THEN amount END)，它省去了每行都做分支判断的开销。实际性能差异取决于数据分布和条件选择性：
- 当过滤条件高选择性（如
status = 'refunded'只占 0.1% 行）且外层无WHERE时，FILTER 和 CASE 的执行计划几乎一致，都是 Seq Scan + Filter - 若已建复合索引
(status, amount)，且你写WHERE status = 'paid'+sum(amount) FILTER (WHERE paid_at > '2025-01-01')，则索引可下推第一层过滤，FILTER 在内存中二次筛，比在 CASE 中重复计算更轻量 - 多个条件聚合并列时（如同时算 success/fail/avg），FILTER 共享一次扫描；而用子查询或 CTE 拆分会导致多次扫描，这才是真正拖慢的关键
FILTER 位置错会导致解析失败而非慢查询
语法错误会直接中断执行，根本不会走到执行计划阶段。这些写法必定报错，不是慢，是根本跑不起来：
-
sum(amount FILTER (WHERE status = 'paid'))→ ERROR: syntax error at or near "FILTER" -
sum(amount) FILTER WHERE status = 'paid'→ ERROR: syntax error at or near "WHERE" -
sum(amount) FILTER (WHERE status IN ($1))→ ERROR: parameter $1 cannot be used in FILTER clause -
count(distinct id) FILTER (WHERE active)→ ERROR: syntax error at or near "FILTER"
正确姿势永远是：聚合函数 + FILTER (WHERE 布尔表达式)，中间不能插任何东西，括号一个都不能少。
和 CASE WHEN 比，FILTER 真正省的是维护成本与隐性陷阱
表面上都是“条件聚合”，但行为差异直接影响结果可信度：
-
avg(score) FILTER (WHERE score > 60)：只用 >60 的非-NULL 行，分母是这些行数 -
avg(CASE WHEN score > 60 THEN score END)：等效，但靠 AVG 自动忽略 NULL —— 安全 -
avg(CASE WHEN score > 60 THEN score ELSE 0 END)：把所有不满足行强行塞进 0，均值严重失真 -
string_agg(name, ', ') FILTER (WHERE active)：天然跳过active = false或name IS NULL行，无多余逗号 -
string_agg(CASE WHEN active THEN name END, ', ')：若某行name为 NULL，CASE返回 NULL，string_agg忽略它，但若误写成ELSE ''，就会产生空字符串+逗号
这些不是性能问题，是统计口径是否可信的问题。一旦上线报表，修复成本远高于调优几毫秒。
空结果返回 NULL 是最容易被前端误读的点
COUNT(*) FILTER (WHERE false) 返回 0，但 SUM(amount) FILTER (WHERE false) 或 AVG() 都返回 NULL。这不是 bug，是标准行为：
- 前端若直接渲染
NULL为 “—” 或空字符串，可能被理解为“该维度无数据”，而实际是“有数据但无匹配条件” - 导出 Excel 时，
NULL被 Excel 当作空单元格，后续公式（如AVERAGE）会静默跳过，导致汇总偏差 - 正确兜底方式是显式用
COALESCE(sum(amount) FILTER (WHERE status = 'paid'), 0)，而不是依赖默认值
这个细节不写进 SQL，再快的执行计划也救不了业务逻辑的歧义。
