MySQL timestamp與時區問題的解決
新項目可能存在國際化的問題，所以花了點時間了解了下 MySQL 和 JDBC 驅動相關的時間問題。看了好多篇博客發現，不少人理解的都是錯誤的，所以結合官方的文檔，重新梳理了一下。
大家都知道在 MySQL 中有兩個專門用來存取日期時間的類型，timestamp 和 datetime。大家總是說 datetime 不包含時區信息，timestamp 存的 utc 時間戳更適合國際化場景下的本地時間轉換。經過了解，上述說法對，但不完全對。
版本信息：
MySQL5.7mysql-connector-java 8.0.31MySQL 用什么類型存日期時間？目前可以存日期時間的數據類型主要分兩類：
bigint：直接將 utc 時間戳存到 int 類型的字段中。后期根據用戶本地時區進行轉換。日期時間類型：timestamp：MySQL 官方定義的時間戳，內部使用 utc 時間戳存儲，但查詢時返回的結果會隨著 session time_zone 的變化而變化。datetime：只存日期時間的值，不包含時區信息。那么我們應該選擇哪個？先說結論在分析，根據需求選 bigint 或 datetime。
類型優點缺點bigint1. 直觀，不需要考慮時區2. 國際化場景直接根據本地時區轉化3. 存儲和查詢效率高1. 數據庫直接查看時可讀性差，需要轉化timestamp無1. 查詢結果收到 session time_zone 的影響，容易出錯2. 最大時間為 2038 年datetime1. 可讀性好2. MySQL 自帶各種操作函數，便于查詢3. 存儲日期范圍大，到 9999 年1. 存儲空間略大2. 查詢效率較前兩者低所以在我看來，如果是后臺管理類的系統，更適合使用 datetime，因為對性能要求沒那么高，并且查詢方便；其他的可以考慮 bigint。
其中最不建議使用的是 timestamp，因為這個會隨著 session time_zone 的變化而變化的，如果開發者對時區理解不深，當服務器或、MySQL 或者 JVM 時區發生變化時，很容易出現問題。
JDBC 驅動和 MySQL 的時區問題剛剛講了 MySQL 的 timestamp 類型的查詢結果會受到 session time_zone 的變化而變化，那么這節我們就來講講時區的問題。
那么從 Springboot Application 到 MySQL，哪些地方存在時區的配置呢？自然是通信的兩端，MySQL 服務端和 MySQL 客戶端。
MySQL Client這里的 Client 是一個籠統的概念，涉及 client 所在機器 os 的時區、對應應用程序的時區（eg: Java 應用就是 JVM 時區）、JDBC 驅動的時區。
機器 OS 時區root@T630-03:/# cat /etc/timezoneAsia/Shanghairoot@T630-03:/# date2023 年 06 月 21 日 星期三 11:20:28 CSTOS 時區影響的是 OS 自身的日期時間命令結果的返回，同時還是影響部分軟件，因為有些軟件會默認使用 OS 時區作為軟件時區。
應用程序時區這里我們 Spring Boot 應用程序為例，對應的就是 JVM 時區，它默認使用的系統時區，可通過輸出 ZoneId.*systemDefault*() 來查看。可通過 TimeZone.setDefault(TimeZone.getTimeZone("America/New_York")); 來配置。主要涉及在 Java 中操作日期和時間的相關類。比如 LocalDateTime.now() ，假設北京時間為 20:00，如果將 TimeZone 設置為 Asia/Tokyo，則會返回 21:00。
JDBC 驅動時區在 Springboot 應用程序中，我們通過 JDBC 驅動來連接到數據庫，在連接的過程中，我們需要配置 jdbcUrl 來指定 JDBC 時區。
在 8.0 的驅動中，是通過配置以下字段指定的：
這兩個參數指定了，通過 JDBC 驅動連接到 MySQL 的 session time_zone 為 Asia/Shanghai。那么通過 JDBC 驅動去調用 SQL 中日期時間相關的方法都會以此時區為準。
connectionTimeZone=Asia/ShanghaiforceConnectionTimeZoneToSession=trueMySQL Server這里的 Server 指的是數據庫，涉及數據庫所在機器 os 的時區、MySQL 的時區。
機器 OS 時區同上，但 MySQL 默認使用的是 OS 時區
MySQL 會話時區mysql> show global variables like '%time_zone%';+------------------+--------+| Variable_name | Value |+------------------+--------+| system_time_zone | CST || time_zone| SYSTEM |+------------------+--------+2 rows in set (0.00 sec)MySQL 有一個默認的時區配置，如上，是使用 OS 時區作為 MySQL 默認時區的。MySQL 其實本身是沒有所謂的時區的，我們所說的都是它的 session time_zone，具體的：
MySQL 存在一個默認時區，一般是 SYSTEM。可通過配置文件或 SQL 進行修改。Client 連接到 MySQL 時若不指定 session time_zone，默認使用 MySQL Server 的時區。也可通過 JdbcUrl 在連接的時候指定或通過 SET time_zone ='UTC'; 指定。Client 在指定了 session time_zone 后，所有的日期時間查詢均會按照所在時區返回結果。timestamp 類型與時區的影響timestamp 在 MySQL 中其實保存就是 UTC 時間戳，當 Client 配置不同的會話時區后，會進行轉換顯示。
下面舉幾個最直觀的例子。
表 time_test，有一個 timestamp 類型的字段 client_time。
直接在 MySQL 控制臺操作
SET time_zone = 'Asia/Shanghai';# 2023-06-20 08:00:00insert into time_test(client_time) values (current_timestamp());select * from time_test ;SET time_zone = 'UTC';# 2023-06-20 00:00:00select * from time_test ;# 2023-06-20 00:01:00insert into time_test(client_time) values (current_timestamp());select * from time_test ;SET time_zone = 'Asia/Shanghai';# 2023-06-20 08:01:00select * from time_test ;? 結果應該很好理解。按照當前時區插入數據后，查詢結果是當前時區的日期，更換時區后，會進行相應的偏移，MySQL 會自動進行轉換。
通過 JDBC 驅動操作? 通過 SpringBoot 調用 JDBC 驅動查詢，雖然中間涉及到了多個時區概念，但其實轉換過程也很簡單。
JVM 時區JVM 日期（假設是 LocalDateTime.now() 返回）JDBC 驅動時區插入后返回的查詢結果Asia/Shanghai2023-06-20 08:00:00Asia/Shanghai2023-06-20 08:00:00Asia/Shanghai2023-06-20 08:00:00UTC2023-06-20 00:00:00Asia/Tokyo2023-06-20 09:00:00Asia/Shanghai2023-06-20 08:00:00Asia/Tokyo2023-06-20 09:00:00UTC2023-06-20 01:00:00說白了，只與 JDBC 驅動的時區有關。
當我們做國際化項目時，只需要保持 JVM 時區和 JDBC 驅動時區一致，均為 Asia/Shanghai。其他用戶，只需要根據設置的本地時區進行轉換即可。
總結一番了解下來，最易用的其實還是bigint和datetime這兩個時區無關的類型，時區相關的操作直接由我們自己控制最理想。并且也沒有timestamp的時間限制。總結下：
優先使用bigint和datetime，國際化在代碼層面做。要使用timestamp，需要了解清楚各種時區的信息并做好配置。防止因為機器時區改變、數據庫時區改變而影響查詢的結果。參考文獻6.3.11 Datetime types processing6.6.1 Preserving Time InstantsSupport for Date-Time Types in Connector/J 8.0到此這篇關于MySQL timestamp與時區問題的解決的文章就介紹到這了,更多相關MySQL timestamp與時區內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！
相關文章：
網公網安備