MySQL 總是差八個小時，如何破？
今天來聊一個簡單的話題，這是一個小伙伴在微信上問我的，對于初學者我非常能理解這類問題帶來的困擾，各種嘗試，各種搜索，別人說的頭頭是道，但是就是解決不了自己的問題，今天我簡單從兩個方面來和大家聊聊這個問題，如果小伙伴們有其他的解決思路，也可以留言一起分享。
這個問題我們可以從兩方面來分析：
- MySQL 本身的問題。
- Java 代碼的問題。
1. MySQL 本身問題
MySQL 本身問題，這個其實很好驗證，不就是時間么，我們執行如下 SQL 看看 MySQL 上的時間跟我的電腦時間是否是一致的：
select now();
可以看到，MySQL 的這個時間跟我系統的時間其實就差了 8 小時，MySQL 本身的時間都不對，那你將來插入/查詢的時間肯定也不對。
這個查詢大家注意，要么使用命令行操作，要么使用 Sqlyog、Navicat 或者 Sequel Pro 之類的數據庫工具來操作，切勿使用 JDBC 來查詢，具體原因一會看完第二小節就明白了。
出現這個問題，多半是 MySQL 的時區不太對，我們重新給其設置一下時區即可。
首先我們通過如下指令來查看一下 MySQL 當前的時區：
show variables like '%time_zone%';
可以看到，MySQL 說它的時區是 SYSTEM，那 SYSTEM 又是啥呢？第一條說了 SYSTEM 是 UTC（協調世界時，又稱世界標準時間或世界協調時間）。而我們的北京時間比 UTC 快了 8 小時，即 UTC+8。
所以我們現在要把 MySQL 的時區先給改對，可以通過修改配置文件來實現（ /etc/mysql/mysql.conf.d/mysqld.cnf ），如下：
修改完成后，重啟 MySQL，再來查看 MySQL 的時區：
可以看到，此時的 MySQL 時區就正常了。
那么此時再執行 select now(); 也就不會有問題了：
有的小伙伴可能嫌修改配置文件太麻煩了，那么也可以通過 SQL 來修改時區：
set global time_zone = Asia/Shanghai
注意我們所在的時區是 Asia/Shanghai，小伙伴們不要自由發揮寫其他城市。
首先我們要確認 MySQL 沒問題。
2. JDBC 連接問題
當確認了 MySQL 沒有問題后，如果你的 MySQL 時間還是不對，那么就有可能是 JDBC 連接的問題了。
這里我用大家常見的 JdbcTemplate 來舉個例子，其他的數據庫框架操作也都是一樣的，我這里主要是演示時區問題，數據操作細節問題就不再展示了。
首先我們來準備一個表，如下：
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 類型。
然后向表中添加一條記錄：
并且這個數據庫的時區是 Asia/Shanghai
接下來我們創建一個 Spring Boot 項目，引入 Web、JDBC API 依賴和 MySQL 驅動，如下：
然后我們來配置一下 MySQL 的連接信息，如下：
spring.datasource.username=root
spring.datasource.password=123
spring.datasource.url=jdbc:mysql:///test01?serverTimezone=UTC
小伙伴們看一下，在數據庫連接地址中，我特意設置了時區為 UTC，這個時區比我們目前的時區慢了 8 小時，我們來看看用這樣一個錯誤的時區，操作的結果是什么樣子的。
@Autowired
JdbcTemplate jdbcTemplate;
@Test
void contextLoads() {
List<User> list = jdbcTemplate.query("select * from user", new BeanPropertyRowMapper<>(User.class));
System.out.println("list = " + list);
}
大家看到，這個查詢結果查到的時間是 21 點，跟 13 點相比快了 8 小時。
為啥呢？
因為我們連接地址中加了 serverTimezone=UTC 參數，這個時候，系統會把從數據庫查詢到的數據當成是 UTC 時區的，即把 13 點當成 UTC 時區的，但是我自己當前設備又是 Asia/Shanghai 時區，UTC 時區的 13 點轉成 Asia/Shanghai 時區之后就是 21 點了。
相同道理，大家也可以自行嘗試設置 serverTimezone=Asia/Tokyo ，時區設置為東京，東京比我們早一個小時，東京的 13 點就是我們的 12 點，那么最終查詢結果就是 12 點。
從這個案例中我們可以看到，jdbc 連接參數中的時區優先級高于 MySQL 服務器的時區參數，所以這個連接參數大家也要尤其注意。
3. 題外話
有的小伙伴遇到的時區問題則是另外一種，返回 JSON 的時候時間不對。
如果在項目中用了 jackson，并且使用 @JsonFormat 注解來格式化日期，就有可能出現時區問題，如下：
@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss",timezone = "Asia/Shanghai")
大家看到，這段代碼如果沒有設置 timezone 屬性，那么默認的時區就是 UTC，也會導致最終的時間差了 8 小時。
4. 小結
好啦，這就是松哥總結的數據庫的幾種情況。
