mysql里CST時區(qū)的坑及解決
一、問題簡述
mysql 里 CST 時區(qū)是個非??拥母拍睿驗樵?mysql 里CST既表示中國也表示美國的時區(qū)。
但是在Jdk代碼里,CST 這個字符串被理解為Central Standard Time (USA)(GMT-6),這就是造成坑的原因。
解決辦法:
mysql 的 time_zone配置 不要用SYSTEM,因為用了就是跟隨 system_time_zone 的值,而 system_time_zone 讀取自數(shù)據(jù)庫所在宿主機的操作系統(tǒng),常常是 CST 的值。
解決辦法是將 time_zone 改成例如 +08:00 以免造成誤解。(肯定改mysql啦,你改得了jdk源碼嗎?)。
修改方法見后文
二、查看、修改時區(qū)
1、怎么查看mysql是什么時區(qū)?
選一個即可
方法1:
命令: 連上mysql后命令行執(zhí)行 show variables like '%time_zone%' (Navicat連上后執(zhí)行也行)
結果:
system_time_zone CST time_zone SYSTEM
看time_zone就行了,SYSTEM表示其值跟隨system_time_zone。
而system_time_zone的CST值,是表示中國呢,還是美國,是不清楚的,你直接再執(zhí)行 select now() 跟你手機的時間對比一下就清楚了。
為什么會system_time_zone和time_zone兩個? 要看哪個? 不急后面會解釋
方法2:
命令:連上mysql后命令行執(zhí)行 (Navicat連上后執(zhí)行也行)
// 分兩次執(zhí)行下面2條命令 select @@system_time_zone; select @@time_zone;
結果:
select @@system_time_zone; +--------------------+ | @@system_time_zone | +--------------------+ | CST | +--------------------+ 1 row in set (4.81 sec) mysql> select @@time_zone; +-------------+ | @@time_zone | +-------------+ | SYSTEM | +-------------+ 1 row in set (0.04 sec)
方法3:
// 查出全局時區(qū)和會話時區(qū) select @@GLOBAL.time_zone,@@SESSION.time_zone;
為什么mysql有system_time_zone和time_zone兩個
見 https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.html
簡單說就是system_time_zone就是mysql服務(即mysqld)啟動的時候讀取數(shù)據(jù)庫所在宿主機的時區(qū),固定下來的值,這個值之后不再改變(除非重啟mysql服務)。time_zone的值未SYSTEM,意思是它的時區(qū)跟system_time_zone一樣(注意system_time_zone的值固定下來后,數(shù)據(jù)庫宿主機的時區(qū)再改變,time_zone的值都是不變的,因為它是跟隨system_time_zone變量的,不是實時跟隨操作系統(tǒng)的)
存在 “為什么linux時區(qū)是對的,但是mysql的時區(qū)是錯的” 的疑惑,因為啟動mysql服務時如果linux時區(qū)是錯的,把mysql的時區(qū)也帶錯了,只是后來你發(fā)現(xiàn)linux時區(qū)錯了于是改對了,但是你忘記啟動mysql的時候linux時區(qū)是錯的,而且你忘了是后來你才把linux的時區(qū)改正確的,所以你有這個的疑惑。我好像也有過這樣的疑惑
2、如何修改mysql的時區(qū)
永久修改,改配置文件,重啟mysql服務也有效
修改 my.cnf 文件,在 [mysqld] 節(jié)下增加 default-time-zone = '+08:00'
沒有這個文件的話,見后文,讓你的mysql啟動的時候讀取配置文件。
臨時修改,重啟mysql服務后丟失
選擇下面之一執(zhí)行即可。
- 修改會話級別定的,關閉會話后就會失效,也僅僅影響當前會話窗口:
set time_zone='+08:00'; - 全局修改,重啟mysql服務后丟失,對所有會話生效:`set global time_zone=’+08:00’;
三、這個bug 是怎么產(chǎn)生的
下面基于mysql-connector-java-8.0.19 進行分析,使用 com.mysql.cj.jdbc.Driver
在獲取java.sql.Connection的過程會確定時區(qū),調用如下方法
com.mysql.cj.protocol.a.NativeProtocol#configureTimezone
/**
* Configures the client's timezone if required.
*
* @throws CJException
* if the timezone the server is configured to use can't be
* mapped to a Java timezone.
*/
public void configureTimezone() {
String configuredTimeZoneOnServer = this.serverSession.getServerVariable("time_zone");
if ("SYSTEM".equalsIgnoreCase(configuredTimeZoneOnServer)) {
configuredTimeZoneOnServer = this.serverSession.getServerVariable("system_time_zone");
}
String canonicalTimezone = getPropertySet().getStringProperty(PropertyKey.serverTimezone).getValue();
if (configuredTimeZoneOnServer != null) {
// user can override this with driver properties, so don't detect if that's the case
if (canonicalTimezone == null || StringUtils.isEmptyOrWhitespaceOnly(canonicalTimezone)) {
try {
canonicalTimezone = TimeUtil.getCanonicalTimezone(configuredTimeZoneOnServer, getExceptionInterceptor());
} catch (IllegalArgumentException iae) {
throw ExceptionFactory.createException(WrongArgumentException.class, iae.getMessage(), getExceptionInterceptor());
}
}
}
if (canonicalTimezone != null && canonicalTimezone.length() > 0) {
this.serverSession.setServerTimeZone(TimeZone.getTimeZone(canonicalTimezone));
//
// The Calendar class has the behavior of mapping unknown timezones to 'GMT' instead of throwing an exception, so we must check for this...
//
if (!canonicalTimezone.equalsIgnoreCase("GMT") && this.serverSession.getServerTimeZone().getID().equals("GMT")) {
throw ExceptionFactory.createException(WrongArgumentException.class, Messages.getString("Connection.9", new Object[] { canonicalTimezone }),
getExceptionInterceptor());
}
}
this.serverSession.setDefaultTimeZone(this.serverSession.getServerTimeZone());
}大概邏輯如下:
- 從mysql的time_zone讀取值
- 如果值是SYSTEM則使用system_time_zone的值
- 如果jdbc url配置了時區(qū)則使用url里的,如 jdbc:mysql://localhost:3306/test?useSSL=true&serverTimezone=Asia/Shanghai獲取的是字符串配置定的
如果獲取到CST,則因為在java里 TimeZone("CST")表示美國中部時間,與mysql數(shù)據(jù)庫用 CST 表示中國時區(qū)的含義就不同了,bug就是這么產(chǎn)生的。
四、其他問題
1、CST究竟是美國還是中國
其實CST總共有4個含義
- China Standard Time:中國標準時間
- Central Standard Time (USA) :美國中部時間(中部就是在國土的中間的部分,例如芝加哥)
- Central Standard Time (Australia):澳大利亞中部時間
- Cuba Standard Time:古巴標準時間
就是因為這個含義不清,所以會有坑,體現(xiàn)在Java里就是:
// 不建議這么創(chuàng)建 TimeZone,這里的CST指的是美國中部時間,不是中國,從
TimeZone tz = TimeZone.getTimeZone("CST");
System.out.println(tz);// 可以看到偏移量是offset=-21600000,-21600000微秒=-6小時,所以實錘這里的CST指美國
// 建議創(chuàng)建 TimeZone 用 ZoneId,因為ZoneId 不允許 CST、JST 這種簡稱,能提前預防進坑,如下
// ZoneId zoneId = ZoneId.of("CST");// 拋異常
ZoneId zoneId = ZoneId.of("GMT+8");// 明確指定,是OK的,或者 "區(qū)域/城市" 的寫法如 Asia/Shanghai
TimeZone tz1 = TimeZone.getTimeZone(zoneId);體現(xiàn)在Mysql里:
你根本不知道m(xù)ysql里的CST是中國還是美國,查出來都展示一樣

(關于system_time_zone和time_zone后續(xù)有解釋)
2、你說CST除了表示中國,也表示美國定的時區(qū),拿得出證據(jù)嗎?
是的!!! 動手做實驗給你看 !!!
使用show variables like '%time_zone%'; 查看mysql的時區(qū),目前是北京時間,查出
Variable_name Value system_time_zone CST time_zone SYSTEM
當把操作系統(tǒng)(mysql的宿主機器的操作系統(tǒng))的時區(qū)改成東京時區(qū),并重啟mysql服務后(必須重啟服務),顯示
Variable_name Value system_time_zone JST time_zone SYSTEM
最后把操作系統(tǒng)時區(qū)改成美國中部時間(如芝加哥),并重啟mysql服務后,顯示
Variable_name Value system_time_zone CST time_zone SYSTEM
可以看到非常坑,無論是中國還是美國,都顯示CST,給人很大的誤解
五、其他
1、mybatis/jdbc 是怎么將日期存入到數(shù)據(jù)庫的,又是怎么查出來的
(這個實在有點復雜,要考慮mysql所在操作系統(tǒng)的時區(qū),也考慮跑你的mysql程序的web服務器的操作系統(tǒng)的時區(qū)。加又沒時間繼續(xù)研究了,緩一緩)
2、再次啰嗦補充
mysql里的 system_time_zone 和 time_zone是什么關系
system_time_zone 是mysql服務啟動時讀取宿主操作系統(tǒng)的時區(qū),當時讀取到什么值就固定什么,是那個時刻的快照。這個值只有在被重新指定或重啟mysql服務的時候才可能變化。
time_zone就是表示所有連接到此mysql的客戶端(client)的時區(qū),不管你是什么形式的客戶端,是java通過jdbc連接的程序,還是Navicat這種圖形化的,還是命令行的,都叫客戶端。這個時區(qū)是可以被覆蓋的,可以被jdbcUrl中的時區(qū)覆蓋。
在jdbc的URL里配置了時區(qū)會怎么樣?
會使用這個時區(qū),在jdbcUrl里指定的時區(qū)優(yōu)先級最高,會覆蓋其他。
例如 jdbc:mysql://localhost:3306/test?useSSL=true&serverTimezone=Asia/Shanghai
- time_zone的SYSTEM是什么意思,是不是指 “操作系統(tǒng)” 的時區(qū)?
- time_zone的SYSTEM,是指值跟隨 system_time_zone 的值,不是說跟隨操作系統(tǒng)的值,操作系統(tǒng)的時區(qū)改了,如果 system_time_zone 不改,則 time_zone 也是不會改的(親自實驗過了!!)
總結
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關文章
Mysql逗號拼接字符串的關聯(lián)查詢以及統(tǒng)計問題
有時為了數(shù)據(jù)庫簡潔,存放數(shù)據(jù)的時候,某一字段采用逗號隔開的形式進行存儲,下面這篇文章主要給大家介紹了關于Mysql逗號拼接字符串的關聯(lián)查詢以及統(tǒng)計問題的相關資料,需要的朋友可以參考下2023-03-03
mysql啟動時出現(xiàn)ERROR 2003 (HY000)問題的解決方法
這篇文章主要為大家詳細介紹了mysql啟動時出現(xiàn)ERROR 2003 (HY000問題的解決方法,具有一定的參考價值,感興趣的小伙伴們可以參考一下2018-03-03
MySQL優(yōu)化之對RAND()的優(yōu)化方法
這篇文章主要介紹了MySQL優(yōu)化之對RAND()的優(yōu)化方法,本文詳細分析了Mysql中對RAND()的幾種優(yōu)化方法,并最終得出一個結論,需要的朋友可以參考下2014-07-07
使用innodb_force_recovery解決MySQL崩潰無法重啟問題
這篇文章主要介紹了使用innodb_force_recovery解決MySQL崩潰無法重啟問題,這只一個成功案例,并不是萬能的解決方法,需要酌情考慮,需要的朋友可以參考下2015-05-05

