当前位置: 首页 > 编程笔记 >

为什么MySQL 使用timestamp可以无视时区问题.

陶鸿畴
2023-03-14
本文向大家介绍为什么MySQL 使用timestamp可以无视时区问题.,包括了为什么MySQL 使用timestamp可以无视时区问题.的使用技巧和注意事项,需要的朋友参考一下

之前一直有过疑惑为什么MySQL数据库存timestamp可以无视时区问题.
在业务中也是一直使用Laravelhtml" target="_blank">框架,内置的Migration也是使用的timestamp类型字段, 也没太关心.

开始

查看当前数据库时区

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

查看表结构

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)

插入数据

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)

这个时间看起来是没问题的, 那么我们尝试修改时区再插入数据

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)

这时候再查看数据, 两条插入的SQL是一样的,但是发现查询的结果是不一样的
这两条数据created_at的相差正好是时区的时间差

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)

再看一下实际存储的时间戳, 然后我们变化时区, 发现字段时间变化了,但是原始的时间戳数据没变

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隐式的帮我们转换了, 让我们不用关心时区的问题

就是数据库实际上会保存 UTC 时间戳,写入的时候先按 Session 时区转成 UTC 时间,读出的时候再按 Session 时区转成当前时区的时间,这些转换都是透明的

  • 假如我们在正八区存储了2020-12-09 08:00:00时间的一条数据
  • 我们在正八区取出这一条数据, 时间依然是2020-12-09 08:00:00
  • 这时候我们有一台在零时区的服务器,连接MySQL,并且把当前连接的时区设置为+00:00,再去查数据库这条记录,查到的数据是:2020-12-09 00:00:00, 正好对应零时区的时间,这样子我们就不用考虑时区的问题.

以上就是为什么MySQL timestamp可以无视时区问题.的详细内容,更多关于MySQL timestamp无视时区的资料请关注小牛知识库其它相关文章!

 类似资料:
  • 问题内容: 我有一个对象,我需要将其以格式插入MySQL的datetime字段中。 这给了我准备好的SQL语句字符串: 无论我指定的时区如何,返回的时间戳都是相同的时间戳。它忽略了我指定的带有时区的Calendar对象。怎么回事,我在做什么错? 问题答案: 时区只是查看日期(这是固定时间点)的不同方式。我在这里写了一个小例子(请注意断言): 此代码段的输出是(结果将根据执行日期/时间而有所不同):

  • 我有充分的证据表明,适用于子菜单(如弹出式上下文菜单或子级菜单)。它用于jQueryUISelectMenu,也用于这个伟大的示例。 我无法确定的是,是否适用于以下两个示例: 信息性弹出窗口,如引导窗口-用于上下文信息,但不包含任何链接

  • 问题内容: 根据MySQL性能Wiki的提示: 拥有或可以使用GROUP BY时,请勿使用DISTINCT。 有人可以发布可以使用GROUP BY代替DISTINCT的查询示例吗? 问题答案: 如果您知道结果中的两列始终直接相关,那么这样做会比较慢: 比这个: 因为在第二种情况下,它只需要比较ID,但是在第一种情况下,它必须比较两个字段。这是MySQL特有的技巧。它不能与其他数据库一起使用。

  • 问题内容: 当Hibernate 将 Java对象 写入 SQL列时,它将日期,计算机日期或日历对象(或其他日期)中指定的日期调整到哪个时区? 当Hibernate 读 的到日历对象,以哪个时区并把它翻译的日期? 问题答案: 当Hibernate将Java Calendar对象写入SQL TIMESTAMP列时,它将日期,计算机日期或Calendar对象(或其他日期)中指定的日期调整到哪个时区?

  • 在PyCharm中,当我写道: 它说“Function call can be replacement with set literal”,所以它将它替换为: 这是为什么?Python中的与字典不同? 如果它想优化这个,为什么这个更有效?