最后的筛选SQL条件应该改为：update_time>=sql_last_value and update_time<now()
空指针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 构建博客检索系统
22917 学习 · 112 问题
相似问题