91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

一文解決MySQL時區相關問題

發布時間:2020-08-11 08:58:20 來源:ITPUB博客 閱讀:165 作者:wang_KJ 欄目:MySQL數據庫

前言:

在使用MySQL的過程中,你可能會遇到時區相關問題,比如說時間顯示錯誤、時區不是東八區、程序取得的時間和數據庫存儲的時間不一致等等問題。其實,這些問題都與數據庫時區設置有關,本篇文章將從數據庫參數入手,逐步介紹時區相關內容。

1.log_timestamps參數介紹

首先說明下 log_timestamps參數并不影響時區,只是設置不同會影響某些日志記錄的時間。該參數主要是控制 error log、slow log、genera log 日志文件中的顯示時間,但不會影響 general log 和 slow log 寫到表 (mysql.general_log, mysql.slow_log) 中的顯示時間。

log_timestamps是全局參數,可動態修改,默認使用UTC時區,這樣會使得日志中記錄的時間比北京時間慢8個小時,導致查看日志不方便。可以修改為SYSTEM變成使用系統時區。下面簡單測試下該參數的作用及修改方法:

# 查看參數值
mysql> show global variables like 'log_timestamps';
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| log_timestamps | UTC   |
+----------------+-------+
1 row in set (0.00 sec)
# 產生慢日志
mysql> select sleep(10),now();
+-----------+---------------------+
| sleep(10) | now()               |
+-----------+---------------------+
|         0 | 2020-06-24 17:12:40 |
+-----------+---------------------+
1 row in set (10.00 sec)
# 慢日志文件記錄內容 發現時間是UTC時間
# Time: 2020-06-24T09:12:50.555348Z
# User@Host: root[root] @ localhost []  Id:    10
# Query_time: 10.000354  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 1
SET timestamp=1592989960;
select sleep(10),now();
# 修改參數值 再次測試
mysql> set global log_timestamps = SYSTEM;
Query OK, 0 rows affected (0.00 sec)
mysql> select sleep(10),now();
+-----------+---------------------+
| sleep(10) | now()               |
+-----------+---------------------+
|         0 | 2020-06-24 17:13:44 |
+-----------+---------------------+
1 row in set (10.00 sec)
# 慢日志文件記錄內容 時間是對的
# Time: 2020-06-24T17:13:54.514413+08:00
# User@Host: root[root] @ localhost []  Id:    10
# Query_time: 10.000214  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 1
SET timestamp=1592990024;
select sleep(10),now();
2.time_zone參數介紹

time_zone參數用來設置每個連接會話的時區,該參數分為全局和會話級別,可以動態修改。默認值為SYSTEM,此時使用的是全局參數system_time_zone的值,而system_time_zone默認繼承自當前系統的時區,即默認情況下MySQL時區和系統時區相同。

時區設置主要影響時區敏感的時間值的顯示和存儲。包括一些函數(如now()、curtime())顯示的值,以及存儲在TIMESTAMP類型中的值,但不影響DATE、TIME和DATETIME列中的值,因為這些數據類型在存取時未進行時區轉換,而TIMESTAMP類型存入數據庫的實際是UTC的時間,查詢顯示時會根據具體的時區來顯示不同的時間。

下面我們來測試下time_zone參數修改產生的影響:

# 查看linux系統時間及時區
[root@centos ~]# date
Sun Jun 28 14:29:10 CST 2020
# 查看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> select now();
+---------------------+
| now()               |
+---------------------+
| 2020-06-28 14:31:12 |
+---------------------+
1 row in set (0.00 sec)
# 創建測試表、插入部分數據
mysql> CREATE TABLE `time_zone_test` (
    ->   `id` int unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
    ->   `dt_col` datetime DEFAULT NULL COMMENT 'datetime時間',
    ->   `ts_col` timestamp DEFAULT NULL COMMENT 'timestamp時間',
    ->   PRIMARY KEY (`id`)
    -> ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='time_zone測試表';
Query OK, 0 rows affected, 1 warning (0.07 sec)
mysql> insert into time_zone_test (dt_col,ts_col) values ('2020-06-01 17:30:00','2020-06-01 17:30:00'),(now(),now());
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0
mysql> select * from time_zone_test;
+----+---------------------+---------------------+
| id | dt_col              | ts_col              |
+----+---------------------+---------------------+
|  1 | 2020-06-01 17:30:00 | 2020-06-01 17:30:00 |
|  2 | 2020-06-28 14:34:55 | 2020-06-28 14:34:55 |
+----+---------------------+---------------------+
# 改為UTC時區 并重新連接 發現timestamp存儲的時間會隨時區變化
mysql> set global time_zone='+0:00';
Query OK, 0 rows affected (0.00 sec)
mysql> set  time_zone='+0:00';
Query OK, 0 rows affected (0.00 sec)
mysql> show global variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CST    |
| time_zone        | +00:00 |
+------------------+--------+
2 rows in set (0.00 sec)
mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2020-06-28 06:36:16 |
+---------------------+
1 row in set (0.00 sec)
mysql> select * from time_zone_test;
+----+---------------------+---------------------+
| id | dt_col              | ts_col              |
+----+---------------------+---------------------+
|  1 | 2020-06-01 17:30:00 | 2020-06-01 09:30:00 |
|  2 | 2020-06-28 14:34:55 | 2020-06-28 06:34:55 |
+----+---------------------+---------------------+
2 rows in set (0.00 sec)
# 改回東八時區,恢復正常
mysql> set global time_zone='+8:00';
Query OK, 0 rows affected (0.00 sec)
mysql> set time_zone='+8:00';
Query OK, 0 rows affected (0.00 sec)
mysql> show global variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CST    |
| time_zone        | +08:00 |
+------------------+--------+
2 rows in set (0.00 sec)
mysql>  select now();
+---------------------+
| now()               |
+---------------------+
| 2020-06-28 14:39:14 |
+---------------------+
1 row in set (0.00 sec)
mysql> select * from time_zone_test;
+----+---------------------+---------------------+
| id | dt_col              | ts_col              |
+----+---------------------+---------------------+
|  1 | 2020-06-01 17:30:00 | 2020-06-01 17:30:00 |
|  2 | 2020-06-28 14:34:55 | 2020-06-28 14:34:55 |
+----+---------------------+---------------------+
2 rows in set (0.00 sec)

如果需要永久生效,還需寫入配置文件中。例如將時區改為東八區,則需要在配置文件[mysqld]部分增加一行:default_time_zone = ‘+8:00’。

3.時區常見問題及如何避免

時區設置不妥可能會產生各種問題,下面我們列舉下幾個常見的問題及解決方法:

3.1 MySQL內部時間不是北京時間

遇到這類問題,首先檢查下系統時間及時區是否正確,然后看下MySQL的time_zone,建議將time_zone改為’+8:00’。

3.2 Java程序存取的時間與數據庫中的時間相差8小時

出現此問題的原因大概率是程序時區與數據庫時區不一致導致的。我們可以檢查下兩邊的時區,如果想統一采用北京時間,則可以在jdbc連接串中增加 serverTimezone=Asia/Shanghai,并且MySQL方面也可以將time_zone改為’+8:00’。

3.3 程序時間與數據庫時間相差13小時或14小時

如果說相差8小時不夠讓人驚訝,那相差13小時可能會讓很多人摸不著頭腦。出現這個問題的原因是JDBC與MySQL對 “CST” 時區協商不一致。因為CST時區是一個很混亂的時區,有四種含義:

  • 美國中部時間 Central Standard Time (USA) UTC-05:00或UTC-06:00
  • 澳大利亞中部時間 Central Standard Time (Australia) UTC+09:30
  • 中國標準時 China Standard Time UTC+08:00
  • 古巴標準時 Cuba Standard Time UTC-04:00

MySQL中,如果time_zone為默認的SYSTEM值,則時區會繼承為系統時區CST,MySQL內部將其認為是UTC+08:00。而jdbc會將CST認為是美國中部時間,這就導致會相差13小時,如果處在冬令時還會相差14個小時。

解決此問題的方法也很簡單,我們可以明確指定MySQL數據庫的時區,不使用引發誤解的CST,可以將time_zone改為’+8:00’,同時jdbc連接串中也可以增加serverTimezone=Asia/Shanghai。

3.4 如何避免出現時區問題

如何避免上述時區問題,可能你心里也有了些方法,簡要總結幾點如下:

  1. 首先保證系統時區準確。
  2. jdbc連接串中指定時區,并與數據庫時區一致。
  3. time_zone參數建議設置為’+8:00’,不使用容易誤解的CST。
  4. 各環境數據庫實例時區參數保持相同。

可能有的同學說了,我們數據庫中time_zone參數選擇的是默認的SYSTEM值,也沒有發生程序時間和數據庫時間不一致的問題。此時是否需要將time_zone改為’+8:00’?在這種情況下還是建議將time_zone改為’+8:00’,特別是經常查詢TIMESTAMP字段,因為當time_zone=system的時候,查詢timestamp字段會調用系統的時區做時區轉換,有全局鎖__libc_lock_lock的保護,可能導致線程并發環境下系統性能受限。而改為’+8:00’則不會觸發系統時區轉換,使用MySQL自身轉換,大大提高了性能。

總結:

讀完本篇文章,你是否對數據庫時區有了更深刻的認識呢。希望這篇文章對你有所幫助,特別是想了解MySQL時區相關內容時,可以拿來多讀讀。如果你遇到過其他時區相關問題,歡迎留言討論。

一文解決MySQL時區相關問題cdn.nlark.com/yuque/0/2020/png/119537/1589445155068-6177cbb4-7921-4c23-b040-7f768ec3ae07.png">

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

松原市| 鸡泽县| 郧西县| 溧阳市| 富锦市| 昌图县| 安义县| 德化县| 财经| 绍兴县| 丰顺县| 堆龙德庆县| 太谷县| 临漳县| 刚察县| 峨眉山市| 昌宁县| 雷山县| 荥阳市| 宝坻区| 和平县| 多伦县| 英山县| 盐池县| 杨浦区| 方城县| 合作市| 定州市| 资讯| 钦州市| 淳化县| 新巴尔虎右旗| 东乡| 肥乡县| 陆河县| 宜良县| 临沭县| 福安市| 衢州市| 江口县| 新丰县|