場景：

我們在mysql客戶端查詢 now() 系統(tǒng)當前日期時間，會發(fā)現(xiàn)得到的結果比系統(tǒng)實際日期時間慢8個小時左右，這是由于不同的時區(qū)導致的

解決：

1、在 mysql 的服務端的 my.conf 文件中 [mysqld] 節(jié)點下設置時區(qū)參數(shù)

default-time-zone=Asia/Shanghai

2、如果 mysql 的版本是 5.7 配置如下參數(shù)

default-time-zone = '+8:00'

3、如果 mysql 服務是由 docker 創(chuàng)建的容器，需要查看 mysql 容器的系統(tǒng)日期是否正確，如果不正確，需要調整 mysql 容器內的系統(tǒng)日期時間

方式一：

//1、把當前宿主機的時區(qū)信息復制到mysql容器的時區(qū)中
docker cp /usr/share/zoneinfo/Asia/Shanghai 容器名稱或Id:etc/localtime
 
//2、重啟mysql服務即可
docker restart 容器名稱或Id

方式二：

共享主機的 localtime，創(chuàng)建容器的時候指定啟動參數(shù)，掛載 localtime 文件到容器內

docker run --name 容器名稱 -v /etc/localtime:/etc/localtime

如此，時區(qū)不一致的問題就解決了

mysql查出時間相差14小時

問題重現(xiàn)

服務器使用mysql 5.7數(shù)據(jù)庫，線上運行程序時，保存時間相差14小時

問題排查

首先以為是線上linux系統(tǒng)數(shù)據(jù)庫時區(qū)問題，特地查看了線上linux數(shù)據(jù)庫時區(qū)

Last login: Wed Nov 27 14:39:13 2019 from 192.168.2.147
[root@localhost ~]# date -R
Thu, 28 Nov 2019 08:44:39 +0800
[root@localhost ~]# hwclock
2019年11月28日 星期四 08時44分52秒  -0.938419 秒
[root@localhost ~]# 

檢查時區(qū)后發(fā)現(xiàn)時區(qū)設置是正確的，懷疑是線上數(shù)據(jù)庫時區(qū)設置問題，檢查線上數(shù)據(jù)庫時區(qū)設置

mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CST    |
| time_zone        | SYSTEM |
+------------------+--------+
2 rows in set (0.03 sec)

發(fā)現(xiàn)線上數(shù)據(jù)庫時區(qū)設置也是一致，于是在本地重新運行程序，添加斷點，監(jiān)聽時間傳參變化，斷點逐步進行，在保存至數(shù)據(jù)庫前，斷點中檢查的時間都是正確的，可以確定是數(shù)據(jù)庫時間保存時出現(xiàn)的問題。

在這個地方我自己遇到的問題更尷尬，排查問題時是在同事電腦上進行排查，檢查了pom文件中依賴的mysql-connector-java 版本號是 5.1.46 ，運行時無報錯信息，但實際打包項目時使用的是我電腦進行打包，但我電腦中pom文件里mysql-connector-java 版本號寫的是runtime，也就是跟著springboot版本選擇，我使用的springboot版本號是2.1.5，所以對應的mysql版本jar包文件是8.0的jar包，就是這個問題導致是時間相差了14小時，更改mysql版本號，重新運行，問題解決。

自己在排查問題過程中也發(fā)現(xiàn)了類似相關的數(shù)據(jù)庫時間保存相差N小時問題主要出于幾種情況：

• 數(shù)據(jù)庫版本不一致 
• marven依賴jar包版本與數(shù)據(jù)庫版本不一致
• mysql時區(qū)設置錯誤
• 系統(tǒng)時區(qū)錯誤

 到此這篇關于解決MySQL時區(qū)日期時差8個小時的問題的文章就介紹到這了,更多相關MySQL差8個小時內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！