ITPub博客

首页 > 数据库 > 数据库开发技术 > MySQL时间戳2038年灾难:你的数据还能撑过去吗?

MySQL时间戳2038年灾难:你的数据还能撑过去吗?

原创 数据库开发技术 作者:数据库干货铺 时间:2023-11-14 18:18:00 0 删除 编辑
点击上方蓝字关注我

Timestamp 类型在MySQL中通常用于存储日期和时间。然而,Timestamp类型的一个限制是其存储范围,它使用4字节(32位)整数来表示秒数,从而导致在2038年01月19日03:14:07之后无法正确存储时间戳。这是因为32位整数最大可表示的秒数是2^31 - 1,即2147483647秒,相当于约68年。因此,如果使用了timestamp类型则需要考虑在达到时间范围前进行相应处理。



1. 案例演示

1.1 创建测试表

创建一张测试表,存储timestamp及 datetime两种类型

CREATE TABLE tb1 (id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,ts TIMESTAMP,dt DATETIME);
插入正常的timestamp及datetime类型数据:均可以写入成功
insert into tb1 (ts, dt) values ('2038-01-01','2038-01-01');

再插入一个超过timestamp范围的数据时,结果如下:

insert into tb1 (ts, dt) values ('2039-01-01','2039-01-01');

报错信息为:

ERROR 1292 (22007): Incorrect datetime value: '2039-01-01' for column 'ts' at row 1

调整一下:可见datetime类型字段可以正常写入超过2038年的时间数据

insert into tb1 (ts, dt) values ('2038-01-01','2039-01-01');

可见,timestamp写入失败,而datetime可正常写入

1. 2  数据范围
因timestamp为4字节,因此最大值为 2147483647 (同int的最大值),换算为时间则为 2038-01-19 03:14:07(UTC时间),即北京时间2038-01-19 11:14:07
而datetime为8个字节,存储时间可超过9999年,理论上足够用


1.3 时区展示问题

由于timestamp类型是时区无关的,因此时区变化时,所展示的数据也是会不一样,因此在处理涉及时区的应用时,需谨慎考虑时差的影响。如不希望变化,可以考虑使用datetime等类型。

mysql> SET SESSION time_zone='+00:00';Query OK, 0 rows affected (0.00 sec)
mysql> select * from tb1;+----+---------------------+---------------------+| id | ts | dt |+----+---------------------+---------------------+| 1 | 2037-12-31 16:00:00 | 2038-01-01 00:00:00 || 2 | 2037-12-31 16:00:00 | 2039-01-01 00:00:00 |+----+---------------------+---------------------+2 rows in set (0.00 sec)
mysql> SET SESSION time_zone='+08:00';Query OK, 0 rows affected (0.01 sec)
mysql> select * from tb1;+----+---------------------+---------------------+| id | ts | dt |+----+---------------------+---------------------+| 1 | 2038-01-01 00:00:00 | 2038-01-01 00:00:00 || 2 | 2038-01-01 00:00:00 | 2039-01-01 00:00:00 |+----+---------------------+---------------------+2 rows in set (0.00 sec)


2. MySQL8.0版本中的改变
MySQL8.0之前,如果使用超过范围的timestamp时会得到如下结果:

mysql> select  version();+---------------+| version()     |+---------------+| 5.7.38-41-log |+---------------+1 row in set (0.00 sec)
mysql> SELECT FROM_UNIXTIME(2147483648);+---------------------------+| FROM_UNIXTIME(2147483648) |+---------------------------+| NULL |+---------------------------+1 row in set (0.00 sec)


而在MySQL8.0版本中(本例使用8.0.33版本),则可以正常获取对应的时间戳值

mysql> select version();+-----------+| version() |+-----------+| 8.0.33-25 |+-----------+1 row in set (0.00 sec)
mysql> SELECT UNIX_TIMESTAMP('2039-01-01');+------------------------------+| UNIX_TIMESTAMP('2039-01-01') |+------------------------------+| 2177424000 |+------------------------------+1 row in set (0.00 sec)



3. 解决方案

如果使用了timestamp类型,且版本较低,可以通过如下方式进行处理。
改为datetime 类型:datetime 类型的范围更广,它能够表示的时间范围是从 '1000-01-01 00:00:00' 到 '9999-12-31 23:59:59'。然而,datetime 类型在存储上可能会占用更多的空间。
使用 bigint 存储时间戳:如果你需要更大的时间范围,并且需要毫秒级别的精度,可以考虑使用 bigint 类型存储时间戳。将时间戳以毫秒或微秒的形式存储在 bigint 字段中,可以更灵活地处理大范围的时间。在这种情况下,你需要在应用中负责将时间戳转换为适当的格式和时区。
数据库升级:如果你的 MySQL版本较低,可以考虑进行数据库升级来解决,且MySQL5.7已经EOL,建议尽快升级至新版本。


往期精彩回顾

1.  MySQL高可用之MHA集群部署

2.  mysql8.0新增用户及加密规则修改的那些事

3.  比hive快10倍的大数据查询利器-- presto

4.  监控利器出鞘:Prometheus+Grafana监控MySQL、Redis数据库

5.  PostgreSQL主从复制--物理复制

6.  MySQL传统点位复制在线转为GTID模式复制

7.  MySQL敏感数据加密及解密

8.  MySQL数据备份及还原(一)

9.  MySQL数据备份及还原(二)

扫码关注     

原文作者:数据库干货铺;如有侵权,请联系管理员删除。

请登录后发表评论 登录
全部评论

注册时间:2019-07-18

  • 博文量
    273
  • 访问量
    66453