建站
咨詢
售后
建站咨詢
新聞中心
今天來聊一個簡單的話題，這是一個小伙伴在微信上問我的，對于初學者我非常能理解這類問題帶來的困擾，各種嘗試，各種搜索，別人說的頭頭是道，但是就是解決不了自己的問題，今天我簡單從兩個方面來和大家聊聊這個問題，如果小伙伴們有其他的解決思路，也可以留言一起分享。
這個問題我們可以從兩方面來分析：
- 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ū)不太對，我們重新給其設置一下時區(qū)即可。
首先我們通過如下指令來查看一下 MySQL 當前的時區(qū)：
show variables like '%time_zone%';
可以看到，MySQL 說它的時區(qū)是 SYSTEM，那 SYSTEM 又是啥呢？第一條說了 SYSTEM 是 UTC（協(xié)調世界時，又稱世界標準時間或世界協(xié)調時間）。而我們的北京時間比 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 驅動，如下：
然后我們來配置一下 MySQL 的連接信息，如下：
spring.datasource.username=root
spring.datasource.password=123
spring.datasource.url=jdbc:mysql:///test01?serverTimezone=UTC
小伙伴們看一下，在數(shù)據(jù)庫連接地址中，我特意設置了時區(qū)為 UTC，這個時區(qū)比我們目前的時區(qū)慢了 8 小時，我們來看看用這樣一個錯誤的時區(qū)，操作的結果是什么樣子的。
@Autowired
JdbcTemplate jdbcTemplate;
@Test
void contextLoads() {
Listlist = jdbcTemplate.query("select * from user", new BeanPropertyRowMapper<>(User.class));
System.out.println("list = " + list);
}
大家看到，這個查詢結果查到的時間是 21 點，跟 13 點相比快了 8 小時。
為啥呢？
因為我們連接地址中加了 serverTimezone=UTC 參數(shù)，這個時候，系統(tǒng)會把從數(shù)據(jù)庫查詢到的數(shù)據(jù)當成是 UTC 時區(qū)的，即把 13 點當成 UTC 時區(qū)的，但是我自己當前設備又是 Asia/Shanghai 時區(qū)，UTC 時區(qū)的 13 點轉成 Asia/Shanghai 時區(qū)之后就是 21 點了。
相同道理，大家也可以自行嘗試設置 serverTimezone=Asia/Tokyo ，時區(qū)設置為東京，東京比我們早一個小時，東京的 13 點就是我們的 12 點，那么最終查詢結果就是 12 點。
從這個案例中我們可以看到，jdbc 連接參數(shù)中的時區(qū)優(yōu)先級高于 MySQL 服務器的時區(qū)參數(shù)，所以這個連接參數(shù)大家也要尤其注意。
3. 題外話
有的小伙伴遇到的時區(qū)問題則是另外一種，返回 JSON 的時候時間不對。
如果在項目中用了 jackson，并且使用 @JsonFormat 注解來格式化日期，就有可能出現(xiàn)時區(qū)問題，如下：
@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss",timezone = "Asia/Shanghai")
大家看到，這段代碼如果沒有設置 timezone 屬性，那么默認的時區(qū)就是 UTC，也會導致最終的時間差了 8 小時。
4. 小結
好啦，這就是松哥總結的數(shù)據(jù)庫的幾種情況。
網頁名稱：MySQL 總是差八個小時，如何破？
網頁鏈接：http://www.dlmjj.cn/article/cceedpj.html
