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

一、年灾难案例演示

1、撑过创建测试表

创建一张测试表，时数据存储timestamp及 datetime两种类型。间戳

复制CREATE TABLE tb1 ( id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,年灾难 ts TIMESTAMP, dt DATETIME );1.2.3.4.5.

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

复制insert into tb1 (ts, dt) values (2038-01-01,2038-01-01);1.

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

复制insert into tb1 (ts, dt) values (2039-01-01,2039-01-01);1.

报错信息为：

复制ERROR 1292 (22007): Incorrect datetime value: 2039-01-01 for column ts at row 11.

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

复制insert into tb1 (ts, dt) values (2038-01-01,2039-01-01);1.

可见，timestamp写入失败，而datetime可正常写入。

2、数据范围

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

3、时区展示问题

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

复制mysql> SET SESSION time_znotallow=+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_znotallow=+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)1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.

二、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)1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.

而在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)1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.

三、亿华云计算解决方案

如果使用了timestamp类型，且版本较低，可以通过如下方式进行处理。

改为datetime 类型

：datetime 类型的范围更广，它能够表示的时间范围是从 1000-01-01 00:00:00 到 9999-12-31 23:59:59。然而，datetime 类型在存储上可能会占用更多的空间。

使用 bigint 存储时间戳

：如果你需要更大的时间范围，并且需要毫秒级别的精度，可以考虑使用 bigint 类型存储时间戳。将时间戳以毫秒或微秒的形式存储在 bigint 字段中，可以更灵活地处理大范围的时间。在这种情况下，你需要在应用中负责将时间戳转换为适当的格式和时区。

数据库升级：如果你的 MySQL版本较低，可以考虑进行数据库升级来解决，且MySQL5.7已经EOL，建议尽快升级至新版本。免费信息发布网