站長(zhǎng)資訊網(wǎng)本篇文章給大家?guī)砹薽ysql中timestamp時(shí)間類型相關(guān)的知識(shí)，mysql中有兩個(gè)時(shí)間類型，timestamp與datetime，希望對(duì)大家有幫助。
眾所周知，mysql中有兩個(gè)時(shí)間類型，timestamp與datetime，但當(dāng)在網(wǎng)上搜索timestamp與datetime區(qū)別時(shí)，會(huì)發(fā)現(xiàn)網(wǎng)上有不少與時(shí)區(qū)有關(guān)的完全相反的結(jié)論，主要兩種：
-
timestamp沒有時(shí)區(qū)問題，而datetime有時(shí)區(qū)問題，原因是timestamp是以UTC格式存儲(chǔ)的，而datetime存儲(chǔ)類似于時(shí)間字符串的形式
-
timestamp也有時(shí)區(qū)問題
兩種觀點(diǎn)讓人迷惑，那timestamp到底會(huì)不會(huì)有時(shí)區(qū)問題呢？
基本概念
時(shí)區(qū)：
由于地域的限制，人們發(fā)明了時(shí)區(qū)的概念，用來適應(yīng)人們?cè)跁r(shí)間感受上的差異，比如中國(guó)的時(shí)區(qū)是東8區(qū)，表示為+8:00，或GMT+8，而日本的時(shí)區(qū)是東9區(qū)，表示為+9:00，或GMT+9，當(dāng)中國(guó)是早上8點(diǎn)時(shí)，日本是早上9點(diǎn)，即東8區(qū)的8點(diǎn)與東9區(qū)的9點(diǎn)，這兩個(gè)時(shí)間是相等的。
另外時(shí)間還有如下兩個(gè)概念：
絕對(duì)時(shí)間：
如unix時(shí)間綴，是1970-01-01 00:00:00開始到現(xiàn)在的秒數(shù)，如：1582416000，這種表示是絕對(duì)時(shí)間，不受時(shí)區(qū)影響，也叫紀(jì)元時(shí)epoch。
本地時(shí)間：
相對(duì)于某一時(shí)區(qū)的時(shí)間，是本地時(shí)間，比如東8區(qū)的2020-02-23 08:00:00，是中國(guó)人的本地時(shí)間，而在此時(shí)，日本人的本地時(shí)間是2020-02-23 09:00:00，所以本地時(shí)間都是與某一時(shí)區(qū)相關(guān)的，脫離時(shí)區(qū)看本地時(shí)間，是沒有意義的，因?yàn)槟悴⒉恢肋@具體是指的什么時(shí)間點(diǎn)。
比如在Java中，Date對(duì)象是絕對(duì)時(shí)間，通過SimpleDateFormat格式化出來的yyyy-MM-dd HH:mm:ss形式的時(shí)間字符串，是本地時(shí)間，如果SimpleDateFormat沒有調(diào)用setTimeZone()顯示指定時(shí)區(qū)，那么默認(rèn)用的是jvm運(yùn)行在的操作系統(tǒng)上的時(shí)區(qū)，我們開發(fā)機(jī)上的時(shí)區(qū)基本都是GMT+8。
timestamp與datetime區(qū)別
如下，我創(chuàng)建了一張表，里面time_stamp是timestamp類型，date_time是datetime類型，create_timestamp、create_datetime是timestamp與datetime類型，但是它們可以由數(shù)據(jù)庫(kù)自動(dòng)生成。
CREATE TABLE `time_test` ( `id` bigint unsigned, `time_stamp` timestamp, `date_time` datetime, `create_timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創(chuàng)建時(shí)間', `create_datetime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創(chuàng)建時(shí)間', PRIMARY KEY (`id`) )
1、首先將數(shù)據(jù)庫(kù)時(shí)區(qū)設(shè)置為+8:00，即中國(guó)的東8區(qū)
2、然后如下手動(dòng)插入一個(gè)固定時(shí)間的數(shù)據(jù)，以及用now()函數(shù)插入當(dāng)前時(shí)間
3、當(dāng)插入完數(shù)據(jù)后，然后我們修改當(dāng)前會(huì)話的時(shí)區(qū)為+9:00，即日本的東9區(qū)，然后再次查看數(shù)據(jù)
4、如上，定義為timestamp類型的列time_stamp、create_timestamp不管是手動(dòng)插入的，還是now()函數(shù)插入的，東9區(qū)都比東8區(qū)的時(shí)間大1個(gè)小時(shí)，這是正確的，說明timestamp類型是時(shí)區(qū)相關(guān)的，然而定義為datetime類型的date_time、create_datetime字段，時(shí)間都沒有變化，這說明datetime類型是時(shí)區(qū)無關(guān)的。
結(jié)論：
timestamp在存儲(chǔ)上是包含時(shí)區(qū)的，而datetime是不包含時(shí)區(qū)，說明網(wǎng)上的第一種說法是對(duì)的。
再看個(gè)例子
我們將東8區(qū)的的2020-02-23 08:00:00轉(zhuǎn)換為unix時(shí)間綴（絕對(duì)時(shí)間），再插入數(shù)據(jù)庫(kù)試試？
如下，使用linux的date命令轉(zhuǎn)換時(shí)間串為unix時(shí)間綴：
$ "date" --date="2020-02-23 08:00:00 +08:00" +%s 1582416000
然后用mysql的from_unixtime()函數(shù)，將unix時(shí)間綴轉(zhuǎn)換為mysql時(shí)間類型來插入數(shù)據(jù)。
如上，查詢出來的時(shí)間，也是東9區(qū)的9點(diǎn)，時(shí)間也是正確的。
為什么網(wǎng)上又說timestamp類型存在時(shí)區(qū)問題？
我發(fā)現(xiàn)網(wǎng)上說timestamp有時(shí)區(qū)問題，都是應(yīng)用端插入數(shù)據(jù)，然后到數(shù)據(jù)庫(kù)中去看，結(jié)果發(fā)現(xiàn)時(shí)間不一樣，因此我打算在Java中寫個(gè)Demo試一下，看能不能重現(xiàn)這個(gè)問題。
1、首先，下面是Java中Entity的定義，與上面的time_test表對(duì)應(yīng)，注意，這里面時(shí)間屬性都是用Date類型定義的，如下：
2、然后，我寫了兩個(gè)接口/insert與/queryAll來插入與查詢數(shù)據(jù)，如下：
3、然后我把數(shù)據(jù)庫(kù)的時(shí)區(qū)設(shè)置為+09:00時(shí)區(qū)，即日本的東9區(qū)，如下：
4、然后調(diào)用/insert接口插入數(shù)據(jù)，注意我接口傳入的時(shí)間是東8區(qū)的8點(diǎn)，如下：
5、插入完后，去數(shù)據(jù)庫(kù)中查詢一把，如下：
可以看到，time_stamp字段時(shí)間是9點(diǎn)，且我已將數(shù)據(jù)庫(kù)時(shí)區(qū)設(shè)置為東9區(qū)，東9區(qū)的9點(diǎn)與東8區(qū)的8點(diǎn)，這兩個(gè)時(shí)間實(shí)際是相等的，因此時(shí)間數(shù)據(jù)沒錯(cuò)。
6、然后我使用/queryAll接口將數(shù)據(jù)查詢出來，如下：
timeStamp屬性是1582416000000，這是毫秒級(jí)的時(shí)間綴，秒級(jí)則是1582416000，對(duì)應(yīng)是東8區(qū)的2020-02-23 08:00:00，時(shí)間數(shù)據(jù)也沒錯(cuò)！
7、然后我又將mysql時(shí)區(qū)修改回+8:00，并重啟我們的java應(yīng)用，如下：
8、再查詢一下數(shù)據(jù)，如下：
timeStamp屬性還是1582416000000，時(shí)間沒有變化，這也是正確的。
那為什么網(wǎng)上會(huì)說timestamp存在時(shí)區(qū)問題？
經(jīng)過一翻查看，我發(fā)現(xiàn)他們都提到了jdbc的serverTimezone，會(huì)不會(huì)是這個(gè)配置錯(cuò)誤導(dǎo)致的呢？就先試試吧！
1、如圖，我把數(shù)據(jù)庫(kù)時(shí)區(qū)修改回+9:00時(shí)區(qū)，然后故意把jdbc的url上的serverTimezone配置為與數(shù)據(jù)庫(kù)不一致的GMT+8時(shí)區(qū)，然后重啟java應(yīng)用，如下：
url: jdbc:mysql://localhost:3306/testdb?serverTimezone=GMT%2B8&useUnicode=true&characterEncoding=utf8
其中GMT%2B8就是GMT+8，因?yàn)樵趗rl上需要urlencode，所以就變成了GMT%2B8。
2、重新插入數(shù)據(jù)，注意插入的時(shí)間還是東8區(qū)的8點(diǎn)，如下：
3、然后，我再到數(shù)據(jù)庫(kù)中查詢一把，如下：
time_stamp中時(shí)間竟然是8點(diǎn)！要知道我們雖然插入的是東8區(qū)的8點(diǎn)，但當(dāng)前會(huì)話可是東9區(qū)的，東8區(qū)的8點(diǎn)等于東9區(qū)的9點(diǎn)，所以正確顯示應(yīng)該為9點(diǎn)才對(duì)，時(shí)間差了1小時(shí)！
4、然后，我又調(diào)用/queryAll接口查詢了一把，想看看mybatis查詢出來的時(shí)間數(shù)據(jù)對(duì)不對(duì)，如下：
可以看到timeStamp是1582416000000，秒級(jí)是1582416000，這個(gè)時(shí)間就是東8區(qū)的8點(diǎn)，東9區(qū)的9點(diǎn)啊！查詢出來的時(shí)間竟然是正確的，為什么？？？
serverTimezone的本質(zhì)
為了找出問題所在，我調(diào)試了一下mysql的jdbc驅(qū)動(dòng)代碼，終于弄明白了原因，主要可以看看如下這幾點(diǎn)：
1.mysql驅(qū)動(dòng)創(chuàng)建連接后，會(huì)調(diào)用com.mysql.jdbc.ConnectionImpl#configureTimezone()來配置此連接的時(shí)區(qū)，如果配置了serverTimezone，則會(huì)使用serverTimezone配置的時(shí)區(qū)，沒配置時(shí)會(huì)去取數(shù)據(jù)庫(kù)中的time_zone變量，這就是為什么我們沒有配置serverTimezone變量時(shí)，結(jié)果也是正確的。
//若使用普通驅(qū)動(dòng)，使用此方法配置mysql連接的時(shí)區(qū) com.mysql.jdbc.ConnectionImpl#configureTimezone() //若使用cj驅(qū)動(dòng)，使用此方法配置mysql連接的時(shí)區(qū) com.mysql.cj.protocol.a.NativeProtocol#configureTimezone()
2.調(diào)用jdbc的setTimestamp()方法時(shí)，實(shí)際調(diào)用的是com.mysql.cj.jdbc.ClientPreparedStatement#setTimestamp()，這里面會(huì)根據(jù)serverTimezone指定的時(shí)區(qū)，將對(duì)應(yīng)的Timestamp對(duì)象轉(zhuǎn)換為serverTimezone指定時(shí)區(qū)的本地時(shí)間字符串。
3.執(zhí)行sql語句時(shí)，會(huì)執(zhí)行com.mysql.cj.jdbc.ClientPreparedStatement#execute()，這里面sendPacket變量保存著真實(shí)會(huì)發(fā)送到mysql的sql語句。
注：看的是8.0.11版本mysql-connector-java驅(qū)動(dòng)源碼，不同版本代碼會(huì)稍有差異，比如5.2.16版本驅(qū)動(dòng)，jdbc url上需要同時(shí)配置這兩個(gè)配置：useTimezone=true&serverTimezone=GMT%2B8，且setTimestamp()對(duì)應(yīng)的是com.mysql.jdbc.PreparedStatement#setTimestampInternal方法。
原理總結(jié)如下：
mysql驅(qū)動(dòng)在發(fā)送sql前，會(huì)將jdbc中的Date對(duì)象參數(shù)，根據(jù)serverTimeZone配置的時(shí)區(qū)轉(zhuǎn)化為日期字符串后，再發(fā)送sql請(qǐng)求給mysql server，同樣在mysql server返回查詢結(jié)果后，結(jié)果中的日期值也是日期字符串，mysql驅(qū)動(dòng)會(huì)根據(jù)serverTimeZone配置的時(shí)區(qū)，將日期字符串轉(zhuǎn)化為Date對(duì)象。
因此，當(dāng)serverTimeZone與數(shù)據(jù)庫(kù)實(shí)際時(shí)區(qū)不一致時(shí)，會(huì)發(fā)生時(shí)區(qū)轉(zhuǎn)換錯(cuò)誤，導(dǎo)致時(shí)間偏差，如下：
a、比如sql參數(shù)是一個(gè)Date對(duì)象，時(shí)間值是東8區(qū)的2020-02-23 08:00:00，注意它里面存儲(chǔ)的可不是2020-02-23 08:00:00這個(gè)字符串，它是Date對(duì)象(絕對(duì)時(shí)間)，只是我用文字表達(dá)出來是東8區(qū)的2020-02-23 08:00:00。
b、然后，由于serverTimeZone配置的是東8區(qū)，mysql驅(qū)動(dòng)會(huì)將這個(gè)Date對(duì)象轉(zhuǎn)為2020-02-23 08:00:00，注意這時(shí)已經(jīng)是字符串了，然后再將sql發(fā)送給mysql，注意這里的sql里面已經(jīng)將Date參數(shù)替換為2020-02-23 08:00:00了，因?yàn)镈ate對(duì)象本身是無法走網(wǎng)絡(luò)的。
c、然后mysql數(shù)據(jù)庫(kù)接收到這個(gè)時(shí)間字符串2020-02-23 08:00:00后，由于數(shù)據(jù)庫(kù)時(shí)區(qū)配置是東9區(qū)，它會(huì)認(rèn)為這個(gè)時(shí)間是東9區(qū)的，它會(huì)以東9區(qū)解析這個(gè)時(shí)間字符串，這時(shí)數(shù)據(jù)庫(kù)保存的時(shí)間是東9區(qū)的2020-02-23 08:00:00，也就是東8區(qū)的2020-02-23 07:00:00，保存的時(shí)間就偏差了1個(gè)小時(shí)。
d、查詢結(jié)果里時(shí)間為什么又對(duì)了呢，因?yàn)椴樵兘Y(jié)果返回了東9區(qū)的時(shí)間字符串，而java應(yīng)用又將其理解為是東8區(qū)的時(shí)間，負(fù)負(fù)得正了！
將serverTimezone與mysql時(shí)區(qū)保持一致
so，那么如果我們將serverTimezone配置改正確，即與數(shù)據(jù)庫(kù)保持一致時(shí)，應(yīng)該查詢到的時(shí)間就會(huì)是錯(cuò)的，會(huì)少1個(gè)小時(shí)。
1、jdbc url中使用與數(shù)據(jù)庫(kù)一樣的東9區(qū)GMT+9，如下：
url: jdbc:mysql://localhost:3306/testdb?serverTimezone=GMT%2B9&useUnicode=true&characterEncoding=utf8
其中的GMT%2B9，即是GMT+9。
2、然后重啟Java應(yīng)用，再查詢一把看看，如下：
返回的是毫秒級(jí)時(shí)間綴1582412400000，秒級(jí)就是1582412400，使用linux的date命令轉(zhuǎn)換為時(shí)間字符串形式：
$ "date" --date="@1582412400" +"%F %T %z" 2020-02-23 07:00:00 +0800
看到?jīng)]，它是東8區(qū)的7點(diǎn)，剛好差了1個(gè)小時(shí)。
3、所以，使用mysql的timestamp類型時(shí)，對(duì)于java應(yīng)用來說，一定要保證jdbc url中的serverTimezone與數(shù)據(jù)庫(kù)中的時(shí)區(qū)配置是一致的。
另外一點(diǎn)是，當(dāng)沒有配置serverTimezone時(shí)，mysql驅(qū)動(dòng)會(huì)自動(dòng)讀取mysql server中配置的時(shí)區(qū)，這里面也有坑！如下：
mysql驅(qū)動(dòng)自動(dòng)讀取數(shù)據(jù)庫(kù)時(shí)區(qū)的坑
3.1 mysql安裝好后，默認(rèn)時(shí)區(qū)是SYSTEM，而SYSTEM指的是system_time_zone變量的時(shí)區(qū)，如下：
3.2 當(dāng)mysql驅(qū)動(dòng)讀到time_zone變量是SYSTEM時(shí)，會(huì)再去讀取system_time_zone變量，而system_time_zone對(duì)于國(guó)內(nèi)來說，默認(rèn)是CST，這是一個(gè)混亂的時(shí)區(qū)，是4個(gè)不同時(shí)區(qū)的縮寫，如下：
對(duì)于Linux或MySQL，會(huì)認(rèn)為CST是中國(guó)標(biāo)準(zhǔn)時(shí)間(+8:00)，但Java卻認(rèn)為CST是美國(guó)標(biāo)準(zhǔn)時(shí)間(-6:00)(注：可能和Java運(yùn)行在Windows中有關(guān))：
如下，linux中CST等于+0800，即中國(guó)時(shí)區(qū)：
$ "date" +"%F %T %Z %z" 2021-09-12 18:35:49 CST +0800
如下，java中CST等于-06:00，美國(guó)時(shí)區(qū)：
3.3 因此mysql驅(qū)動(dòng)取到CST這個(gè)時(shí)區(qū)值時(shí)，它會(huì)以為這是-6:00時(shí)區(qū)，但MySQL卻理解為+8:00時(shí)區(qū)，因此MySQL時(shí)區(qū)一定不要配置為CST，而要配置為具體的時(shí)區(qū)，如+8:00，但如果MySQL時(shí)區(qū)為CST且不可修改的情況下，一定要配置jdbc的serverTimezone為清晰的時(shí)區(qū)(如：GMT+8)。
Entity中日期屬性是String呢？
1、我們將Entity對(duì)象中的時(shí)間屬性改為String（不推薦），如下：
2、然后也寫兩個(gè)接口，/insert2與/queryAll2，如下：
3、然后插入數(shù)據(jù)，注意這時(shí)我是直接將無時(shí)區(qū)的8點(diǎn)，作為參數(shù)給到sql的，如下：
4、然后再查詢一把，如下：
如上所示，time_stamp字段值是8點(diǎn)，但此時(shí)數(shù)據(jù)庫(kù)時(shí)區(qū)是東9區(qū)，所以這是東9區(qū)的8點(diǎn)。
5、然后我將數(shù)據(jù)庫(kù)與jdbc中serverTimezone都改為東8區(qū)呢，改完后重啟Java應(yīng)用，如下：
url: jdbc:mysql://localhost:3306/testdb?serverTimezone=GMT%2B8&useUnicode=true&characterEncoding=utf8
6、再次插入數(shù)據(jù)，參數(shù)還是無時(shí)區(qū)的8點(diǎn)，如下：
7、再查詢一把，如下：
如上所示，time_stamp字段值是8點(diǎn)，但現(xiàn)在數(shù)據(jù)庫(kù)時(shí)間是東8區(qū)，所以這是東8區(qū)的8點(diǎn)。
8、然后我再將jdbc url上的serverTimezone調(diào)整為東9區(qū)，然后重啟Java應(yīng)用，如下：
url: jdbc:mysql://localhost:3306/testdb?serverTimezone=GMT%2B9&useUnicode=true&characterEncoding=utf8
現(xiàn)在serverTimezone與數(shù)據(jù)庫(kù)中不一致，數(shù)據(jù)庫(kù)是東8區(qū)，serverTimezone是東9區(qū)。
9、我們?cè)俅尾迦霟o時(shí)區(qū)的8點(diǎn)，如下：
10、然后再查詢一把，如下：
time_stamp字段值還是8點(diǎn)，數(shù)據(jù)庫(kù)是東8區(qū)，所以這是東8區(qū)的8點(diǎn)，但我們serverTimezone與數(shù)據(jù)庫(kù)的時(shí)區(qū)不一致啊，沒看到時(shí)間有偏差，為什么？
解釋一下
前面說過了，對(duì)于jdbc中的Date對(duì)象，在發(fā)送給mysql前，會(huì)先根據(jù)serverTimezone轉(zhuǎn)換為相應(yīng)時(shí)區(qū)的時(shí)間字符串，但現(xiàn)在Entity中時(shí)間屬性是String類型，mysql驅(qū)動(dòng)不會(huì)進(jìn)行轉(zhuǎn)換，所以不管serverTimezone怎么配置，對(duì)String類型的時(shí)間串都沒影響。
這樣的話，似乎java中日期類型用時(shí)間字符串來存還好些，不容易出錯(cuò)，但請(qǐng)?jiān)僬J(rèn)真考慮一下，調(diào)用方傳了一個(gè)無時(shí)區(qū)的8點(diǎn)，數(shù)據(jù)庫(kù)自作主張，就將其認(rèn)為是東9區(qū)的8點(diǎn)，但如果這個(gè)時(shí)間字符串實(shí)際是東8區(qū)的8點(diǎn)呢？這時(shí)如果保存到數(shù)據(jù)庫(kù)中為東9區(qū)的8點(diǎn)，那數(shù)據(jù)就存錯(cuò)了！
那如果目前api接口就傳的無時(shí)區(qū)的時(shí)間串，Entity中就定義的String，怎么解決呢？
1、詢問接口定義人員，這個(gè)接口的時(shí)間串指的是哪個(gè)時(shí)區(qū)的，比如是東8區(qū)的2020-02-23 08:00:00。
2、然后接口接收到時(shí)間后，要以東8區(qū)將時(shí)間字符串轉(zhuǎn)換為Date對(duì)象，如下：
SimpleDateFormat sdf = new SimpleDateFormat('yyyy-MM-dd HH:mm:ss'); sdf.setTimeZone(TimeZone.getTimeZone("GMT+8")); Date date = sdf.parse("2020-02-23 08:00:00");
3、然后如果Entity中時(shí)間屬性定義的是String，那么我們要再將Date對(duì)象以數(shù)據(jù)庫(kù)的時(shí)區(qū)格式化為對(duì)應(yīng)的時(shí)間字符串，比如數(shù)據(jù)庫(kù)時(shí)區(qū)是東9區(qū)，那么格式化后就是2020-02-23 09:00:00，如下：
SimpleDateFormat sdf = new SimpleDateFormat('yyyy-MM-dd HH:mm:ss'); sdf.setTimeZone(TimeZone.getTimeZone("GMT+9")); String dateStr = sdf.format(date); entity.setTimeStamp(dateStr);
4、然后將Entity保存到mysql中的，就也會(huì)是東9區(qū)的2020-02-23 09:00:00，結(jié)果正確。
所以，使用String類型來存儲(chǔ)時(shí)間數(shù)據(jù)，要想將時(shí)間值保存正確，超級(jí)麻煩，不建議在實(shí)際開發(fā)中這種使用。
最佳實(shí)踐
1、大多數(shù)團(tuán)隊(duì)會(huì)規(guī)定api中傳遞時(shí)間要用unix時(shí)間綴，因?yàn)槿绻銈饕粋€(gè)2020-02-23 08:00:00時(shí)間值，它到底是哪個(gè)時(shí)區(qū)的8點(diǎn)呢？對(duì)于unix時(shí)間綴，就不會(huì)有此問題，因?yàn)樗墙^對(duì)時(shí)間。而如果某些特殊原因，一定要使用時(shí)間字符串，最好使用ISO8601規(guī)范那種帶時(shí)區(qū)的時(shí)間串，比如：2020-02-23T08:00:00+08:00。
2、Mybatis中Entity定義要與數(shù)據(jù)庫(kù)定義一致，數(shù)據(jù)庫(kù)中是timestamp，那么Entity中要定義為Date對(duì)象，因?yàn)閙ysql驅(qū)動(dòng)在執(zhí)行sql時(shí)，會(huì)自動(dòng)根據(jù)serverTimezone配置幫你轉(zhuǎn)換為數(shù)據(jù)庫(kù)時(shí)區(qū)的時(shí)間串，如果你自己來轉(zhuǎn)換，你極有可能因?yàn)橥浾{(diào)用setTimeZone()方法，而使用當(dāng)前java應(yīng)用所在機(jī)器的默認(rèn)時(shí)區(qū)，一旦java應(yīng)用所在機(jī)器的時(shí)區(qū)與數(shù)據(jù)庫(kù)的時(shí)區(qū)不一致，就會(huì)出現(xiàn)時(shí)區(qū)問題。
3、jdbc的serverTimezone參數(shù)，要配置正確，當(dāng)不配置時(shí)，mysql驅(qū)動(dòng)會(huì)自動(dòng)讀取mysql server的時(shí)區(qū)，此時(shí)一定要將mysql server的時(shí)區(qū)指定為清晰的時(shí)區(qū)(如：+08:00)，切勿使用CST。
4、如果數(shù)據(jù)庫(kù)時(shí)區(qū)修改后，jdbc的serverTimezone也要跟著修改，并重啟Java應(yīng)用，就算沒有配置serverTimezone，也需要重啟，因?yàn)閙ysql驅(qū)動(dòng)初始化連接時(shí)，會(huì)將當(dāng)前數(shù)據(jù)庫(kù)時(shí)區(qū)緩存到一個(gè)java變量中，不重啟Java應(yīng)用它不會(huì)變。
數(shù)據(jù)庫(kù)中用timestamp還是int來存儲(chǔ)時(shí)間？
如果用int型時(shí)間綴存儲(chǔ)，不管數(shù)據(jù)庫(kù)時(shí)區(qū)是啥，都不影響，因?yàn)榇鎯?chǔ)的是絕對(duì)時(shí)間，看起來完美解決了時(shí)區(qū)問題。
但從某些角度看，這種方案只是把時(shí)區(qū)問題從數(shù)據(jù)庫(kù)端推到應(yīng)用端去了，時(shí)區(qū)問題將出現(xiàn)在將時(shí)間字符串轉(zhuǎn)換為時(shí)間綴的過程中，比如某程序員從api接口中拿到時(shí)間字符串后，沒考慮時(shí)區(qū)，直接轉(zhuǎn)為unix時(shí)間綴，就可能出現(xiàn)時(shí)區(qū)問題。
因此，對(duì)于不帶時(shí)區(qū)的時(shí)間串解析，一定要問清楚這是哪個(gè)時(shí)區(qū)的時(shí)間，并在代碼中顯式指定！
另外，用int存儲(chǔ)時(shí)間還有如下3個(gè)不好的點(diǎn)：
-
開發(fā)人員看到這個(gè)字段后，無法一目了然的了解到這個(gè)時(shí)間綴大概是個(gè)什么時(shí)間，需要去轉(zhuǎn)換一下，會(huì)很繁瑣。
-
像update_time這樣的字段，數(shù)據(jù)庫(kù)提供了DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP的機(jī)制，這樣在更新任何字段時(shí)，update_time會(huì)自動(dòng)更新，而如果使用int存儲(chǔ)，就需要程序員每次更新表時(shí)，重新set這個(gè)字段，容易遺忘。
-
由于int只有4個(gè)字節(jié)，用它來存儲(chǔ)時(shí)間，會(huì)在2038年后溢出，而對(duì)于timestamp來說，MySQL將其底層存儲(chǔ)統(tǒng)一修改為8個(gè)字節(jié)，相對(duì)來說還是比較容易的。
當(dāng)然，也并不是建議不用int，這是見仁見智的，不管用timestamp還是int，都沒有致命性問題的。
總結(jié)
timestamp本身是沒有時(shí)區(qū)問題的，時(shí)區(qū)問題是由于serverTimezone配置錯(cuò)誤、mysql使用CST這種混亂時(shí)區(qū)或Entity中將日期定義String類型導(dǎo)致的。
推薦學(xué)習(xí)：mysql視頻教程
