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

点击上方蓝字关注我

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

1. 案例演示

1.1 创建测试表

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

sql 复制代码
CREATE TABLE tb1 (
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
ts TIMESTAMP,
dt DATETIME
);

插入正常的timestamp及datetime类型数据:均可以写入成功

sql 复制代码
insert into tb1 (ts, dt) values ('2038-01-01','2038-01-01');

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

sql 复制代码
insert into tb1 (ts, dt) values ('2039-01-01','2039-01-01');

报错信息为:

cs 复制代码
ERROR 1292 (22007): Incorrect datetime value: '2039-01-01' for column 'ts' at row 1

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

sql 复制代码
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等类型。

ruby 复制代码
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时会得到如下结果:

diff 复制代码
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版本),则可以正常获取对应的时间戳值

cs 复制代码
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数据库

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

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

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

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

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

扫码关注

相关推荐
zhangjin122216 分钟前
kettle从入门到精通 第九十四课 ETL之kettle MySQL Bulk Loader大批量高性能数据写入
大数据·数据仓库·mysql·etl·kettle实战·kettlel批量插入·kettle mysql
深圳厨神25 分钟前
mysql对表,数据,索引的操作sql
数据库·sql·mysql
谁家有个大人27 分钟前
数据分析问题思考路径
数据库·数据分析
hweiyu0029 分钟前
从JVM到分布式锁:高并发架构设计的六把密钥
jvm·redis·分布式·mysql·etcd
小陈又菜36 分钟前
MySQL-触发器
数据库·mysql·database·触发器
爱的叹息41 分钟前
详解隔离级别(4种),分别用表格展示问题出现的过程及解决办法
数据库·oracle
平凡的小y42 分钟前
MySQL内置函数
数据库·mysql
佩奇的技术笔记1 小时前
中级:MyBatis面试题深度剖析
数据库·mybatis
慕丹1 小时前
虫洞数观系列三 | 数据分析全链路实践:Pandas清洗统计 + Navicat可视化呈现
python·mysql·数据挖掘·数据分析·pandas
luluoluoa1 小时前
SQL、mySQL与SQLite简单理解
sql·mysql·sqlite