vanpeisi7

详细的 explain：

Finalize Aggregate (cost=425545.45..425545.46 rows=1 width=8) (actual time=522.040..573.976 rows=1 loops=1)
-> Gather (cost=425545.23..425545.44 rows=2 width=8) (actual time=521.286..573.949 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Partial Aggregate (cost=424545.23..424545.24 rows=1 width=8) (actual time=494.321..494.322 rows=1 loops=3)
-> Parallel Index Only Scan using bz_switchcover_open_close_time_c_idx on bz_switchcover (cost=0.43..421581.16 rows=1185629 width=0) (actual time=20.590..487.712 rows=9267 loops=3)
Index Cond: ((open_time <= '2023-07-16 23:59:59'::timestamp without time zone) AND (close_time >= '2023-07-16 00:00:00'::timestamp without time zone))
Heap Fetches: 18
Planning Time: 0.184 ms
JIT:
Functions: 11
Options: Inlining false, Optimization false, Expressions true, Deforming true
Timing: Generation 1.365 ms, Inlining 0.000 ms, Optimization 1.067 ms, Emission 17.333 ms, Total 19.766 ms
Execution Time: 574.577 ms

@whoami9426

```
Finalize Aggregate (cost=362425.35..362425.36 rows=1 width=8)
-> Gather (cost=362425.14..362425.35 rows=2 width=8)
Workers Planned: 2
-> Partial Aggregate (cost=361425.14..361425.15 rows=1 width=8)
-> Parallel Index Only Scan using bz_switchcover_open_close_time_c_idx on bz_switchcover (cost=0.43..358436.32 rows=1195526 width=0)
Index Cond: ((open_time <= '2023-05-11 23:59:59'::timestamp without time zone) AND (close_time >= '2023-05-11 00:00:00'::timestamp without time zone))
JIT:
Functions: 5
Options: Inlining false, Optimization false, Expressions true, Deforming true

```

单纯的加上 limit 和 offset 分页查询是很快的，几十 ms ，就是 count 太耗时了。

select
*
from
switch.bz_switchcover
where
close_time>= '2023-05-01 00:00:00'
and open_time <= '2323-05-01 23:59:59'
order by open_time desc
limit 15 offset 0
;

我使用的 Spring Cloud Stream 和 RabbitMq 的镜像队列

@Octopvs 多个线程同时更新，A 和 B 都更新这种问题也不行。1.A 获取缓存 ； 2.B 获取缓存； 3.B 更新数据库、删除缓存； 4.A 更新数据库（用的数据是早先从缓存获取的），删除缓存

@UltraXiaoZi 原来如此，终于明白了，我原以为 spring-rabbitmq 和 rabbitmq 中的 auto 是一样的。

@wolfie 我理解的主要区别，就是 manaul 手动 ack ，如果出现异常，可以进行捕获，然后进行 basicNack ，basicNack 时候，requeue 设置为 true ，消息会重回队列。出现异常时，消息一直不断的消费和 requeue 进入队列，这样能保证消息不丢失。如果是 autoAct ，出现异常，没法做特殊处理，然后被 SimpleMessageListenerContainer 自动 ack 掉了。如果使用 autoAck,出现异常也进行捕获，然后对异常做处理（比如循环重试，直到成功），这样是否也能保证不丢失消息。