SUM(CASE WHEN)变慢主因是优化器难下推索引预过滤，必须全表扫描后逐行计算；应优先WHERE提前过滤、建联合索引，并考虑FILTER子句或物化中间结果。
为什么SUM(CASE WHEN)在大数据量下会变慢
不是CASE WHEN本身慢，而是它让优化器很难利用索引做预过滤。比如SUM(CASE WHEN status = 'Completed' THEN amount ELSE 0 END)这个表达式，数据库必须先读出每一行的status和amount，再逐行判断、累加——哪怕你只想要某几个region的数据，也得扫完整个分区或表。
更麻烦的是，如果CASE WHEN里混用了不同列（比如同时判断status和product_category），且这些列没建联合索引，WHERE阶段就无法有效剪枝，rows预估会飙升。
- 执行计划里出现
type=ALL或type=index，且rows远大于实际匹配数 -
Extra字段含Using where; Using temporary，说明连GROUP BY都触发了临时表 - 聚合字段上用了函数或表达式（如
UPPER(status)），直接导致索引失效
用FILTER子句替代CASE WHEN（PostgreSQL专属）
PostgreSQL 9.4+ 支持FILTER子句，语义更清晰，且优化器更容易下推条件。它和CASE WHEN逻辑等价，但写法更紧凑，也更利于后续可能的向量化执行优化。
把原来这样写的：
SUM(CASE WHEN status = 'Completed' THEN amount ELSE 0 END)
换成：
SUM(amount) FILTER (WHERE status = 'Completed')
关键区别：
-
FILTER是语法级支持，不是表达式，优化器能明确识别这是“带条件的聚合”，有机会提前应用索引 - 不用写
ELSE 0，避免类型隐式转换风险（比如amount是DECIMAL，0被当成INTEGER） - 多个条件可叠加：
COUNT(*) FILTER (WHERE status = 'Completed' AND region = 'US')
提前WHERE过滤 + 聚合字段单独建索引
最有效的提速方式，往往不是改写SELECT，而是让扫描范围变小。别指望聚合函数自己“聪明地跳过不相关行”——你得帮它把无关数据在早期就拦住。
例如要统计每个region下status = 'Completed'的销售额，不要只靠GROUP BY region硬扛：
- 在
WHERE里先限定大范围：WHERE status IN ('Completed', 'Shipped')（比全表扫描好） - 给高频过滤+分组组合建联合索引：
CREATE INDEX idx_orders_status_region_amount ON orders (status, region, amount)——注意顺序：等值条件status放最左，region次之，amount放最后（覆盖索引，避免回表） - 如果
status基数太低（比如只有3个值），考虑用部分索引：CREATE INDEX idx_orders_completed_region ON orders (region, amount) WHERE status = 'Completed'
物化中间结果（适合固定报表场景）
当多条件SUM是每天定时跑的报表，且原始表更新不频繁（比如订单表只增不改），硬扛实时计算就是自找麻烦。用物化视图或汇总表把结果“存下来”，查询时直接SELECT * FROM sales_summary_by_region，性能差距可能是百倍级。
PostgreSQL可用CREATE MATERIALIZED VIEW；MySQL可用定期INSERT INTO summary_table SELECT ... GROUP BY + TRUNCATE + INSERT双表切换；ClickHouse直接建ReplacingMergeTree汇总表。
重点提醒：别在物化逻辑里还套着复杂CASE WHEN——先在源表上加好索引，让物化过程本身也快；同时记得加刷新机制（定时任务或触发器），否则数据就 stale 了。
真正卡住性能的，往往不是语法多优雅，而是有没有让数据库少读一行不该读的数据。
