最后的筛选SQL条件应该改为:update_time>=sql_last_value and update_time<now()

来源:4-2 logstash全量、增量同步解决方案

空指针1

2020-04-21 16:03

SQL where条件为:              update_time>sql_last_value   的问题在于会遗漏临界点数据,解决思路应该是将临界点数据包含进来

老师给出的解决方案SQL是: update_time>sql_last_value   and update_time<now()

就是在上面的SQL筛选条件上又加了一个筛选条件,无需理解SQL的业务含义,就可知下面SQL的数据范围比上面的小,上面的大范围没有包含的数据,就不可能在一个比上面还小的范围里。即临界点数据没有被上面的sql查询到,就不可能被下面的sql查询到。所以老师最后给出的sql并没有解决临界点数据问题,正确的SQL应该是将下面的>改为>=(我想这应该是老师的一个手误)

这样的话,临界点的数据就交给了下一次同步任务查出来,不会忽略以及重复查询

写回答 关注

4回答

  • 慕田峪9281056
    2022-01-21 03:01:45


    假如2022:01:01 00:01插100条

    第一次搜
    >1979:01:01 00:00 < 2022:01:01 00:01

    你可能根本就搜不出来,因为条件是少于当时系统时间00:01
    其实就是搜索了
    >1979:01:01 00:00 < 2020:01:01 00:00这个范围而已

    所以这时候插入的数据根本没匹配到数据
    注意这里保存的时间点可能是00:00,但绝对不是00:01

    所以第二次搜的时候是>00:00而不是>00:01

    >2022:01:01 00:00 < 2022:05:05 00:01

    这里为什么是00:00而不是00:01呢,因为第一次搜的时候是记录<少于不是=的时间点

    其实老师这个语法只是把当前时间插入的100条数据放弃搜索不处理而是供给下次执行搜索的范围做条件

  • 慕田峪9281056
    2022-01-21 02:59:45


    假如2022:01:01 00:01插100条

    第一次搜
    >1979:01:01 00:00 < 2022:01:01 00:01

    你可能根本就搜不出来,因为条件是少于当时系统时间00:01
    其实就是搜索了
    >1979:01:01 00:00 < 2020:01:01 00:00这个范围而已

    所以这时候插入的数据根本没匹配到数据
    注意这里保存的时间点可能是00:00,但绝对不是00:01

    所以第二次搜的时候是>00:00而不是>00:01

    >2022:01:01 00:00 < 2022:05:05 00:01

    这里为什么是00:00而不是00:01呢,因为第一次搜的时候是记录<少于不是=的时间点

    其实老师这个语法只是把当前时间插入的100条数据放弃搜索不处理而是供给下次执行搜索的范围做条件

  • 网络时空
    2021-07-16 23:41:03

    我同意楼主的观点,感觉老师的写法,少了等号,一定会漏掉增量数据!

  • Robot_l
    2020-08-06 20:45:09

    我也是跟你一样的想法,除非..........这个sql_last_value指的是同步时最后一条数据的更新时间?

Springboot + ElasticSearch 构建博客检索系统

Springboot + ElasticSearch 构建个人博客检索系统

22961 学习 · 112 问题

查看课程

相似问题