MySQL-同步或刷历史数据专题-根据修改时间-扫描最近3天3小时的数据-最近几天-最近几小时
最近3天 最近3小时的数据
and m.update_time > DATE_SUB(now(), INTERVAL 3 DAY)
and m.update_time > DATE_SUB(now(), INTERVAL 3 HOUR)
实际场景下，看看是否需要 加上create_time。如果新建数据时，没有写入update_time ，那就要加上create_time
dateTime:
and (m.create_time > DATE_SUB(now(), INTERVAL 3 DAY) or m.update_time > DATE_SUB(now(), INTERVAL 3 DAY) )
时间戳：
and ( FROM_UNIXTIME(created_at) > DATE_SUB(now(), INTERVAL 3 DAY) or FROM_UNIXTIME(last_modified) > DATE_SUB(now(), INTERVAL 3 DAY) )
如果是定时任务使用场景：
1、加一个缓存，记录上次处理的时间，根据业务场景灵活判断需要扫描最近几天的数据。
2、直接写到表中，也是记录上次处理的时间，直接根据当前时间减去表中上次执行的时间得到需要处理最近几天的数据，（根据这个思路，可以简化下，扫描的数据时间 > 上次执行的时间就行，至于是否有几秒或更长时间的差距，具体问题具体分析 ）。
同步 & 推数据逻辑：
syncDeviceSystemTime 为空 要同步
syncDeviceSystemTime 不为空 时间1 ，修改时间2 ，修改时间>上次同步时间1 要同步 用这个做个补偿吧 and (syncDeviceSystemTime is null or DATE_FORMAT(syncDeviceSystemTime,'%Y-%m') = '0000-00' or last_modified > syncDeviceSystemTime )
记得syncDeviceSystemTime 更新now(),(更新syncDeviceSystemTime的时候，修改时间理论上也会同时更新，所以尽量同时加上修改时间=修改时间)
感觉比同步最近3天的更好，不过上面的每同步到一个业务系统，都要新增一个上次同步时间的字段
有个特殊的场景注意：
1、lastDay在代码内部不要取默认值，放在外部，更灵活
2、通过lastDay查询有变化的userIdList后，再去统计对应userIdList业务数据时，不要在加上lastDay，因为统计的维度是人，不是最近几天，业务上最多可能是月度、年度
更多相关逻辑见
《MySQL-同步或刷历史数据专题-判断一个周期内不要重复重复执行任务-到期前30天提醒-开始前10分钟提醒》
《Java-同步或刷历史数据专题-分页刷数据-几种分页模板》
正文到此结束
热门推荐
相关文章
近期评论
-
来自： 运维-docker专题-创建镜像-操作容器-制作jdk17的docker镜像等
-
来自： 留言板
-
来自： 留言板
-
来自： js-处理网页图片宽度自适应屏幕宽度
-
来自： 留言板
