前言

今天來聊一個簡單的話題，這是一個小伙伴在微信上問我的，對于初學(xué)者我非常能理解這類問題帶來的困擾，各種嘗試，各種搜索，別人說的頭頭是道，但是就是解決不了自己的問題，今天我簡單從兩個方面來和大家聊聊這個問題，如果小伙伴們有其他的解決思路，也可以留言一起分享。

這個問題我們可以從兩方面來分析：

• MySQL 本身的問題。
• Java 代碼的問題。

1. MySQL 本身問題

MySQL 本身問題，這個其實很好驗證，不就是時間么，我們執(zhí)行如下 SQL 看看 MySQL 上的時間跟我的電腦時間是否是一致的：

select now();

可以看到，MySQL 的這個時間跟我系統(tǒng)的時間其實就差了 8 小時，MySQL 本身的時間都不對，那你將來插入/查詢的時間肯定也不對。

這個查詢大家注意，要么使用命令行操作，要么使用 Sqlyog、Navicat 或者 Sequel Pro 之類的數(shù)據(jù)庫工具來操作，切勿使用 JDBC 來查詢，具體原因一會看完第二小節(jié)就明白了。

出現(xiàn)這個問題，多半是 MySQL 的時區(qū)不太對，我們重新給其設(shè)置一下時區(qū)即可。

首先我們通過如下指令來查看一下 MySQL 當前的時區(qū)：

show variables like '%time_zone%';

可以看到，MySQL 說它的時區(qū)是 SYSTEM，那 SYSTEM 又是啥呢？第一條說了 SYSTEM 是 UTC（協(xié)調(diào)世界時，又稱世界標準時間或世界協(xié)調(diào)時間）。而我們的北京時間比 UTC 快了 8 小時，即 UTC+8。

所以我們現(xiàn)在要把 MySQL 的時區(qū)先給改對，可以通過修改配置文件來實現(xiàn)（/etc/mysql/mysql.conf.d/mysqld.cnf），如下：

修改完成后，重啟 MySQL，再來查看 MySQL 的時區(qū)：

可以看到，此時的 MySQL 時區(qū)就正常了。

那么此時再執(zhí)行 select now(); 也就不會有問題了：

有的小伙伴可能嫌修改配置文件太麻煩了，那么也可以通過 SQL 來修改時區(qū)：

set global time_zone = Asia/Shanghai

注意我們所在的時區(qū)是 Asia/Shanghai，小伙伴們不要自由發(fā)揮寫其他城市。

首先我們要確認 MySQL 沒問題。

2. JDBC 連接問題

當確認了 MySQL 沒有問題后，如果你的 MySQL 時間還是不對，那么就有可能是 JDBC 連接的問題了。

這里我用大家常見的 JdbcTemplate 來舉個例子，其他的數(shù)據(jù)庫框架操作也都是一樣的，我這里主要是演示時區(qū)問題，數(shù)據(jù)操作細節(jié)問題就不再展示了。

首先我們來準備一個表，如下：

CREATE TABLE `user` (
  `id` int NOT NULL AUTO_INCREMENT,
  `createTime` datetime DEFAULT NULL,
  `updateTime` timestamp NULL DEFAULT NULL,
  `username` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

很簡單的幾個字段，createTime 是 datetime 類型，updateTime 是 Timestamp 類型。

然后向表中添加一條記錄：

并且這個數(shù)據(jù)庫的時區(qū)是 Asia/Shanghai

接下來我們創(chuàng)建一個 Spring Boot 項目，引入 Web、JDBC API 依賴和 MySQL 驅(qū)動，如下：

然后我們來配置一下 MySQL 的連接信息，如下：

spring.datasource.username=root
spring.datasource.password=123
spring.datasource.url=jdbc:mysql:///test01?serverTimezone=UTC

小伙伴們看一下，在數(shù)據(jù)庫連接地址中，我特意設(shè)置了時區(qū)為 UTC，這個時區(qū)比我們目前的時區(qū)慢了 8 小時，我們來看看用這樣一個錯誤的時區(qū)，操作的結(jié)果是什么樣子的。

@Autowired
JdbcTemplate jdbcTemplate;
@Test
void contextLoads() {
    List<User> list = jdbcTemplate.query("select * from user", new BeanPropertyRowMapper<>(User.class));
    System.out.println("list = " + list);
}

大家看到，這個查詢結(jié)果查到的時間是 21 點，跟 13 點相比快了 8 小時。

為啥呢？

因為我們連接地址中加了 serverTimezone=UTC 參數(shù)，這個時候，系統(tǒng)會把從數(shù)據(jù)庫查詢到的數(shù)據(jù)當成是 UTC 時區(qū)的，即把 13 點當成 UTC 時區(qū)的，但是我自己當前設(shè)備又是 Asia/Shanghai 時區(qū)，UTC 時區(qū)的 13 點轉(zhuǎn)成 Asia/Shanghai 時區(qū)之后就是 21 點了。

相同道理，大家也可以自行嘗試設(shè)置 serverTimezone=Asia/Tokyo，時區(qū)設(shè)置為東京，東京比我們早一個小時，東京的 13 點就是我們的 12 點，那么最終查詢結(jié)果就是 12 點。

從這個案例中我們可以看到，jdbc 連接參數(shù)中的時區(qū)優(yōu)先級高于 MySQL 服務(wù)器的時區(qū)參數(shù)，所以這個連接參數(shù)大家也要尤其注意。

3. 題外話

有的小伙伴遇到的時區(qū)問題則是另外一種，返回 JSON 的時候時間不對。

如果在項目中用了 jackson，并且使用 @JsonFormat 注解來格式化日期，就有可能出現(xiàn)時區(qū)問題，如下：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss",timezone = "Asia/Shanghai")

大家看到，這段代碼如果沒有設(shè)置 timezone 屬性，那么默認的時區(qū)就是 UTC，也會導(dǎo)致最終的時間差了 8 小時。

4. 小結(jié)

到此這篇關(guān)于MySQL總是差八個小時該如何解決的文章就介紹到這了,更多相關(guān)MySQL差八個小時內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論