最近項目上正好遇到點關(guān)于SQL 時間戳的問題， 查了一下資料發(fā)現(xiàn)和原來意想中的不太一樣，權(quán)且記錄并分享。
問題的起因是這樣的，有兩個跨服務器的數(shù)據(jù)庫DATA1 和DATA2 ，上面分別有表A和表B, 兩個表中都有 類型的字段，假設都叫time。
A和B表結(jié)構(gòu)
現(xiàn)在想要用定時任務，實現(xiàn)當A表有更新時，即往B表中插入一條A表的數(shù)據(jù)，兩表之間用id關(guān)聯(lián)。本來我是這么寫的：
大致是這么個意思：從A表中取數(shù)據(jù)往B表里插，但滿足兩個條件之一：
（1）A里有B沒有的，這就是第一個not 條件；
（2）A,B都有，但是A表記錄的時間戳比B表最新的時間戳還要新的。
這么寫完當時試了下沒有問題，從A表里更新和新增的數(shù)據(jù)也都能插進去，
于是就掛成了定時任務。
第二天在查看數(shù)據(jù)的時候，發(fā)現(xiàn)數(shù)據(jù)量很大，感覺不對勁，于是仔細看了下，發(fā)現(xiàn)B表的重復數(shù)據(jù)挺多，很明顯并非是A表真正的有頻繁修改導致的。
經(jīng)過定位分析，發(fā)現(xiàn)是time字段的問題。不管是什么樣的情況下，A表的time字段始終大于B表的字段，所以導致腳本會一直執(zhí)行。
我原本的理解時間戳字段sql查詢系統(tǒng)時間戳，肯定是記錄最新的更新次序，更新完B表后，時間戳肯定要大于A表的時間戳嘛，結(jié)果不是，于是搜了下，發(fā)現(xiàn)真是理解有誤。
網(wǎng)上的資料是這么解釋的：
也就是說，首先時間戳并不是時間也不能表示時間，它是一個二進制數(shù)字的類型，每次表記錄更新時都會更新該列，因此它也確實可以用來比對數(shù)據(jù)是否被更新，但是要注意，它所表示 的是 相對次序，標黑了 ：相對。
結(jié)合下面那段話，也就是說，是在同一個數(shù)據(jù)庫里的相對次序，如果上面的例子中A和B表是在同一數(shù)據(jù)庫，那是沒有問題的。
于是用 @@DBTS在兩個數(shù)據(jù)庫里執(zhí)行的結(jié)果，對比了一下發(fā)現(xiàn)真是不一樣，也驗證了我的想法，就是不同庫對應的時間戳初始值是不一樣的，所以沒有可比性sql查詢系統(tǒng)時間戳，比如DATA1中的時間戳都跑到1千萬了，DATA2中才到100，那A表中的時間戳值可不是永遠都比B表中的時間戳值大么？
好了，查到原因，就知道解決方法了，我想到兩個方法：
（1）在DATA1庫中建立表B，這樣對比A和B的時間戳就有意義了；
（2）換個方式比對，在兩個表中都加字段time2, 字段類型為()，默認值()，然后在判斷的時候根據(jù)time2的時間來判斷。
兩個方法都可以實現(xiàn)，歡迎評論區(qū)討論！