最后的篩選SQL條件應該改為：update_time>=sql_last_value and update_time<now()
SQL where條件為：? ? ? ? ? ? ? update_time>sql_last_value? ?的問題在于會遺漏臨界點數(shù)據(jù)，解決思路應該是將臨界點數(shù)據(jù)包含進來
老師給出的解決方案SQL是： update_time>sql_last_value? ?and update_time<now()
就是在上面的SQL篩選條件上又加了一個篩選條件，無需理解SQL的業(yè)務含義，就可知下面SQL的數(shù)據(jù)范圍比上面的小，上面的大范圍沒有包含的數(shù)據(jù)，就不可能在一個比上面還小的范圍里。即臨界點數(shù)據(jù)沒有被上面的sql查詢到，就不可能被下面的sql查詢到。所以老師最后給出的sql并沒有解決臨界點數(shù)據(jù)問題，正確的SQL應該是將下面的>改為>=(我想這應該是老師的一個手誤)
這樣的話，臨界點的數(shù)據(jù)就交給了下一次同步任務查出來，不會忽略以及重復查詢
2022-01-21
假如2022:01:01 00:01插100條
第一次搜
>1979:01:01 00:00 < 2022:01:01 00:01
你可能根本就搜不出來，因為條件是少于當時系統(tǒng)時間00:01
其實就是搜索了
>1979:01:01 00:00 < 2020:01:01 00:00這個范圍而已
所以這時候插入的數(shù)據(jù)根本沒匹配到數(shù)據(jù)
注意這里保存的時間點可能是00:00，但絕對不是00:01
所以第二次搜的時候是>00:00而不是>00:01
>2022:01:01 00:00 < 2022:05:05 00:01
這里為什么是00:00而不是00:01呢，因為第一次搜的時候是記錄<少于不是=的時間點
其實老師這個語法只是把當前時間插入的100條數(shù)據(jù)放棄搜索不處理而是供給下次執(zhí)行搜索的范圍做條件
2022-01-21
假如2022:01:01 00:01插100條
第一次搜
>1979:01:01 00:00 < 2022:01:01 00:01
你可能根本就搜不出來，因為條件是少于當時系統(tǒng)時間00:01
其實就是搜索了
>1979:01:01 00:00 < 2020:01:01 00:00這個范圍而已
所以這時候插入的數(shù)據(jù)根本沒匹配到數(shù)據(jù)
注意這里保存的時間點可能是00:00，但絕對不是00:01
所以第二次搜的時候是>00:00而不是>00:01
>2022:01:01 00:00 < 2022:05:05 00:01
這里為什么是00:00而不是00:01呢，因為第一次搜的時候是記錄<少于不是=的時間點
其實老師這個語法只是把當前時間插入的100條數(shù)據(jù)放棄搜索不處理而是供給下次執(zhí)行搜索的范圍做條件
2021-07-16
我同意樓主的觀點，感覺老師的寫法，少了等號，一定會漏掉增量數(shù)據(jù)！
2020-08-06
我也是跟你一樣的想法，除非..........這個sql_last_value指的是同步時最后一條數(shù)據(jù)的更新時間?