最后的篩選SQL條件應該改為：update_time>=sql_last_value and update_time<now()
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-21
假如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-21
假如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
我同意樓主的觀點，感覺老師的寫法，少了等號，一定會漏掉增量數據！
2020-08-06
我也是跟你一樣的想法，除非..........這個sql_last_value指的是同步時最后一條數據的更新時間?