为何添加分组过滤条件后TimescaleDB查询反而变慢？

这问题真的反直觉——本来想着提前把分组范围缩小，能减少后面子查询要处理的对象，结果反而慢了一倍多，咱们对着执行计划拆解下原因：

核心问题：优化器选了更“低效”的执行计划 #

两个查询的执行计划差异是关键：

1. 3秒的原查询：
   优化器走的是批量处理路线：先对group表全表扫描（Seq Scan）+ 排序，再和device关联后对activity做HashAggregate，一次性找出所有有2天内活动的分组ID，最后再通过反连接排除1天内有活动的分组。这种方式是把所有符合条件的activity数据一次性处理完，再和group关联，属于“先聚合再匹配”，效率很高。

2. 8秒的慢查询：
   加了planned_end >= current_timestamp - interval '7 days'后，优化器发现group表有对应索引（complex_key），于是选了逐行嵌套循环路线：

   • 先通过索引扫描找出少数符合条件的分组（执行计划里rows=2）
   • 对每个分组，分别执行两次子查询（exists和not exists），也就是每遍历一个分组，就要去扫一次activity的相关chunk
     看起来分组少了，但每个分组对应的activity扫描是重复执行的，累加起来的成本远高于一次性批量扫描activity的成本。

为什么优化器会选错？ #

PostgreSQL的优化器是基于“成本估算”的，它觉得：既然符合条件的分组只有2个，那对每个分组跑一次子查询的总成本会很低。但它低估了activity表的查询成本——哪怕是单个分组，对应的activity数据量也很大，两次子查询的开销加起来，比一次性扫描所有相关activity再聚合要高得多。

怎么解决？ #

咱们可以手动引导优化器回到批量处理的路线，比如把查询重写成“先聚合activity找出候选分组，再和group表关联”的形式：

WITH candidate_group_ids AS (
    -- 先找出所有有2天内活动，但1天内无活动的分组ID
    SELECT d.group_id
    FROM activity act
    JOIN device d ON act.device_id = d.id
    WHERE act.date >= current_timestamp - interval '2 day'
    EXCEPT
    SELECT d.group_id
    FROM activity act
    JOIN device d ON act.device_id = d.id
    WHERE act.date >= current_timestamp - interval '1 day'
)
-- 再关联符合条件的分组
SELECT g.*
FROM "group" g
JOIN candidate_group_ids cg ON g.id = cg.group_id
WHERE g.state = 'enabled'
  AND g.planned_end >= current_timestamp - interval '7 days';

另外也可以检查下索引是否合理：

• 给activity表建(date, device_id)的复合索引，加速时间范围和设备ID的关联
• 给group表建(state, planned_end)的复合索引，让分组过滤更高效

内容来源于stack exchange