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

MySQL时间戳2038年灾难:你的数据还能撑过去吗?点击上方蓝字关注我 Timestamp 类型在 MySQL 中通常用于存储日期和时间 然而 Timestamp 类型的一个限制是其存储范围 它使用 4 字节 32 位 整数来表示秒数 从而导致在 2038 年 01 月 19 日 03 14 07 之后无法正确存储时间戳 这是因为 32 位整数最大可表示的秒数是 2 31 1

大家好,我是讯享网,很高兴认识大家。

点击上方蓝字关注我

252326df2c2788f5133c18b90fd69bc2.png
讯享网

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');

0af802921405d27ca5049e93f6694127.png

再插入一个超过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

4c65ab8a868edfd05a33bb42ab3bf8f6.png

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

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

a318f9c16fcaf85d8eff1132a9b1d096.png

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

1. 2  数据范围

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

1.3 时区展示问题

讯享网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)

558bf3da7dfe89b0cfe78a434a8c2bf1.png

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(); +---------------------------+ | FROM_UNIXTIME() | +---------------------------+ | NULL | +---------------------------+ 1 row in set (0.00 sec)

76dcf3cf1737786672f931bc370f8247.png

讯享网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') | +------------------------------+ |  | +------------------------------+ 1 row in set (0.00 sec)

cc34bbd9130e5c9f74d5c3f12cf3b159.png

3. 解决方案

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

0e812471cfeb3b203083da3111b4219e.png

往期精彩回顾

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

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

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

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

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

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

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

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

16be6876f05844cd562e1323e93ac0cd.png

4b24074a5ef3162e8d1ee49082e991f8.jpeg

fa73f4ccfdf5ebe0d751037ceaf2060a.png

d15b746c92182cd1396e6a07f6591de5.png

小讯
上一篇 2025-01-29 20:17
下一篇 2025-03-15 23:27

相关推荐

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/24792.html