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