校园春色亚洲色图_亚洲视频分类_中文字幕精品一区二区精品_麻豆一区区三区四区产品精品蜜桃

主頁 > 知識庫 > 為什么MySQL 使用timestamp可以無視時區(qū)問題.

為什么MySQL 使用timestamp可以無視時區(qū)問題.

熱門標(biāo)簽:福州呼叫中心外呼系統(tǒng)哪家好 天智外呼系統(tǒng) 房產(chǎn)智能外呼系統(tǒng)品牌 云南語音外呼系統(tǒng)平臺 北京人工外呼系統(tǒng)價錢 沃克斯電梯外呼線路圖 地圖標(biāo)注被騙三百怎么辦 400電話鄭州申請 常州電銷外呼系統(tǒng)一般多少錢

之前一直有過疑惑為什么MySQL數(shù)據(jù)庫存timestamp可以無視時區(qū)問題.
在業(yè)務(wù)中也是一直使用Laravel框架,內(nèi)置的Migration也是使用的timestamp類型字段, 也沒太關(guān)心.

開始

查看當(dāng)前數(shù)據(jù)庫時區(qū)

mysql> show variables like "%time_zone%";
+------------------+--------+
| Variable_name  | Value |
+------------------+--------+
| system_time_zone | CST  |
| time_zone    | +08:00 |
+------------------+--------+
2 rows in set (0.30 sec)

查看表結(jié)構(gòu)

mysql> desc timestamp_test;
+--------------+-----------+------+-----+---------+----------------+
| Field    | Type   | Null | Key | Default | Extra     |
+--------------+-----------+------+-----+---------+----------------+
| id      | int    | NO  | PRI | NULL  | auto_increment |
| created_time | datetime | YES |   | NULL  |        |
| created_at  | timestamp | YES |   | NULL  |        |
+--------------+-----------+------+-----+---------+----------------+
3 rows in set (0.26 sec)

插入數(shù)據(jù)

mysql> insert into timestamp_test(created_time, created_at) values('2020-12-09 08:00:00', '2020-12-09 08:00:00');
Query OK, 1 row affected (0.22 sec)


mysql> select * from timestamp_test;
+----+---------------------+---------------------+
| id | created_time    | created_at     |
+----+---------------------+---------------------+
| 1 | 2020-12-09 08:00:00 | 2020-12-09 08:00:00 |
+----+---------------------+---------------------+
1 row in set (0.06 sec)

這個時間看起來是沒問題的, 那么我們嘗試修改時區(qū)再插入數(shù)據(jù)

mysql> SET time_zone = "+00:00";
Query OK, 0 rows affected (0.03 sec)

mysql> insert into timestamp_test(created_time, created_at) values('2020-12-09 08:00:00', '2020-12-09 08:00:00');
Query OK, 1 row affected (0.03 sec)

mysql> SET time_zone = "+08:00";
Query OK, 0 rows affected (0.04 sec)

這時候再查看數(shù)據(jù), 兩條插入的SQL是一樣的,但是發(fā)現(xiàn)查詢的結(jié)果是不一樣的
這兩條數(shù)據(jù)created_at的相差正好是時區(qū)的時間差

mysql> select * from timestamp_test;
+----+---------------------+---------------------+
| id | created_time    | created_at     |
+----+---------------------+---------------------+
| 1 | 2020-12-09 08:00:00 | 2020-12-09 08:00:00 |
| 2 | 2020-12-09 08:00:00 | 2020-12-09 16:00:00 |
+----+---------------------+---------------------+
2 rows in set (0.06 sec)

再看一下實際存儲的時間戳, 然后我們變化時區(qū), 發(fā)現(xiàn)字段時間變化了,但是原始的時間戳數(shù)據(jù)沒變

mysql> select *, unix_timestamp(created_at) from timestamp_test;
+----+---------------------+---------------------+----------------------------+
| id | created_time    | created_at     | unix_timestamp(created_at) |
+----+---------------------+---------------------+----------------------------+
| 1 | 2020-12-09 08:00:00 | 2020-12-09 08:00:00 |         1607472000 |
| 2 | 2020-12-09 08:00:00 | 2020-12-09 16:00:00 |         1607500800 |
+----+---------------------+---------------------+----------------------------+
2 rows in set (0.06 sec)

mysql> SET time_zone = "+00:00";
Query OK, 0 rows affected (0.09 sec)

mysql> show variables like "%time_zone%";
+------------------+--------+
| Variable_name  | Value |
+------------------+--------+
| system_time_zone | CST  |
| time_zone    | +00:00 |
+------------------+--------+
2 rows in set (0.08 sec)

mysql> select *, unix_timestamp(created_at) from timestamp_test;
+----+---------------------+---------------------+----------------------------+
| id | created_time    | created_at     | unix_timestamp(created_at) |
+----+---------------------+---------------------+----------------------------+
| 1 | 2020-12-09 08:00:00 | 2020-12-09 00:00:00 |         1607472000 |
| 2 | 2020-12-09 08:00:00 | 2020-12-09 08:00:00 |         1607500800 |
+----+---------------------+---------------------+----------------------------+
2 rows in set (0.18 sec)

因為這一切是MySQL隱式的幫我們轉(zhuǎn)換了, 讓我們不用關(guān)心時區(qū)的問題

就是數(shù)據(jù)庫實際上會保存 UTC 時間戳,寫入的時候先按 Session 時區(qū)轉(zhuǎn)成 UTC 時間,讀出的時候再按 Session 時區(qū)轉(zhuǎn)成當(dāng)前時區(qū)的時間,這些轉(zhuǎn)換都是透明的

  • 假如我們在正八區(qū)存儲了2020-12-09 08:00:00時間的一條數(shù)據(jù)
  • 我們在正八區(qū)取出這一條數(shù)據(jù), 時間依然是2020-12-09 08:00:00
  • 這時候我們有一臺在零時區(qū)的服務(wù)器,連接MySQL,并且把當(dāng)前連接的時區(qū)設(shè)置為+00:00,再去查數(shù)據(jù)庫這條記錄,查到的數(shù)據(jù)是:2020-12-09 00:00:00, 正好對應(yīng)零時區(qū)的時間,這樣子我們就不用考慮時區(qū)的問題.

以上就是為什么MySQL timestamp可以無視時區(qū)問題.的詳細內(nèi)容,更多關(guān)于MySQL timestamp無視時區(qū)的資料請關(guān)注腳本之家其它相關(guān)文章!

您可能感興趣的文章:
  • MySQL timestamp的類型與時區(qū)實例詳解
  • 通過實例解析MySql CURRENT_TIMESTAMP函數(shù)
  • MySQL的時間差函數(shù)TIMESTAMPDIFF、DATEDIFF的用法
  • MySQL的時間差函數(shù)(TIMESTAMPDIFF、DATEDIFF)、日期轉(zhuǎn)換計算函數(shù)(date_add、day、date_format、str_to_date)
  • MySQL中datetime和timestamp的區(qū)別及使用詳解
  • MySQL 5.6 中 TIMESTAMP有那些變化
  • MySQL 5.6 中的 TIMESTAMP 和 explicit_defaults_for_timestamp 參數(shù)
  • Mysql中的Datetime和Timestamp比較
  • mysql 數(shù)據(jù)類型TIMESTAMP

標(biāo)簽:拉薩 沈陽 沈陽 黔東 鹽城 珠海 徐州 移動

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《為什么MySQL 使用timestamp可以無視時區(qū)問題.》,本文關(guān)鍵詞  為什么,MySQL,使用,timestamp,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《為什么MySQL 使用timestamp可以無視時區(qū)問題.》相關(guān)的同類信息!
  • 本頁收集關(guān)于為什么MySQL 使用timestamp可以無視時區(qū)問題.的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章
    主站蜘蛛池模板: 高台县| 石狮市| 全椒县| 宕昌县| 略阳县| 高要市| 吉首市| 新乡市| 融水| 牟定县| 汕头市| 平远县| 富民县| 华安县| 神木县| 阿城市| 安塞县| 出国| 石门县| 吉木乃县| 林甸县| 革吉县| 泾阳县| 册亨县| 天长市| 河北区| 顺义区| 云南省| 鄢陵县| 长乐市| 塔城市| 田林县| 台安县| 青龙| 上高县| 永仁县| 白水县| 伊春市| 稷山县| 怀宁县| 汨罗市|