SQL where条件为： update_time>sql_last_value 的问题在于会遗漏临界点数据，解决思路应该是将临界点数据包含进来
老师给出的解决方案SQL是： update_time>sql_last_value and update_time<now()
就是在上面的SQL筛选条件上又加了一个筛选条件，无需理解SQL的业务含义，就可知下面SQL的数据范围比上面的小，上面的大范围没有包含的数据，就不可能在一个比上面还小的范围里。即临界点数据没有被上面的sql查询到，就不可能被下面的sql查询到。所以老师最后给出的sql并没有解决临界点数据问题，正确的SQL应该是将下面的>改为>=(我想这应该是老师的一个手误)
这样的话，临界点的数据就交给了下一次同步任务查出来，不会忽略以及重复查询
假如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条数据放弃搜索不处理而是供给下次执行搜索的范围做条件
假如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条数据放弃搜索不处理而是供给下次执行搜索的范围做条件
我同意楼主的观点，感觉老师的写法，少了等号，一定会漏掉增量数据！
我也是跟你一样的想法，除非..........这个sql_last_value指的是同步时最后一条数据的更新时间?