前言

有些数据需要到未来某个时刻生效或失效，比如双十二的价格，这些数据会提前存在业务表中，之后不断用定时任务去扫描这些数据，如果存在要生效或失效的，就取出来处理。简单来说，就是定时用sql来查询这些数据。另外，也可以用redis存储这些数据，定时去redis取这些数据。

sql扫描

给时间字段添加索引，提高sql查询的效率。

alter table XXX add index idx_time_field (time_field)

如果数据量特别大的话，建议分页查询，避免一次查询把内存撑爆。

select * from XXX limit 0,1000

limit两个参数，随着第一个参数不断增大（limit 5000000,1000），查询会变得越来越慢。

所以考虑用另一种分页的写法。

select row_id,* from XXX where row_id>last_row_id order by row_id limit 1000

这种写法用主键作为排序字段，然后每次查询代入上一页的最大主键（第一页是0）作为查询条件，并使用单参数limit。快的原因是用了主键的索引。

如果后续处理逻辑比较耗时，建议分页查出来后，异步去处理这些数据，避免一个定时任务周期内，有数据没有扫描出来并处理。

redis存储

毕竟，如果查询优化器检测到索引字段大部分都是相同的数据（区分度不高），会忽略索引，进行全表扫描。这时候就会比较难受了。

既然mysql的索引不好用，就用redis来提高检索效率。

选取键

因为是根据时间去找数据，所以可以根据时间戳（秒）去作为键去组织数据。

假设某些数据2021-12-12 00:00:00生效，2021-12-13 00:00:00失效，那么分别计算这两个时刻（秒）：

结果如下：

那么可以把所有要生效的数据放入PREFIX:1639267200所对应的set中，所有要失效的数据放入PREFIX:1639353600的set中。

简单的说，以时间戳（未来的）作为键，set作为值。

定时任务扫键

之前已经把要生效的数据放入了redis的键中，剩下的就是定时任务去扫这些键。

假设定时任务周期是5s，那么每次定时任务触发时，取出当前时刻和前5秒时刻（取决于定时任务周期）的所有键。

为了方便处理，需要把每次定时任务扫描的键unionStore到一个单独的键S，处理完后删除。（S里面包含的所有键也删除）

考虑到这个单独的键S可以比较大，所以使用distinctRandomMember每次取出1000个。

建议异步消费这些数据，确保一个定时任务周期内分发完这些数据。

总结

1. 使用索引来提高查询效率
2. 分批避免内存OOM
3. 索引失效时，使用redis存储数据并快速检索
4. 异步处理数据，在一个定时任务周期内分发完所有的数据