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