前言

本文的原文连接是:
https://blog.csdn.net/freewebsys/article/details/127455169

未经博主允许不得转载。
博主CSDN地址是：https://blog.csdn.net/freewebsys
博主掘金地址是：https://juejin.cn/user/585379920479288
博主知乎地址是：https://www.zhihu.com/people/freewebsystem

1，关于MySQL时间戳的2038年BUG

在linux 设计上，使用了int代表时间，当时设计的还不错。

当 timestamp 存储的时间大于 ‘2038-01-19 03:14:07’ UTC，mysql就会报错，
因为这是 mysql自身的问题，也就是说 timestamp是有上限的，超过了，自然会报错。

timestamp的时间范围是：‘1970-01-01 00:00:01’ UTC to ‘2038-01-19 03:14:07’ UTC ，自动时区转化，实际存储毫秒数，4字节存储
datetime的时间范围：‘1000-01-01 00:00:00’ to ‘9999-12-31 23:59:59’ ，不支持时区，8字节存储

但是真的到了2038年会咋样呢？

2，使用Docker创建MySQL 模拟下

在默认的Linux 系统上开启了时间同步需要停止下，然后直接设置成2038年2月1日。
创建表之后在修改时间，在linux 系统上进行修改。
不是进入docker 环境中修改。

sudo systemctl stop systemd-timesyncdsudo date -s 20380202
[sudo] test 的密码：
2038年 02月 02日 星期二 00:00:00 CST

这里需要使用最新的myslq 版本。因为5.7 好像日期变了直接异常了：
起码DBA是要在这之前升级到新版本，忙活了。

2038-02-01T16:00:14.626767Z 6 [Warning] Iteration 1: Current time obtained from system is greater than 2038
2038-02-01T16:00:14.626778Z 6 [Warning] Iteration 2: Current time obtained from system is greater than 2038
2038-02-01T16:00:14.626786Z 6 [Warning] Iteration 3: Current time obtained from system is greater than 2038
2038-02-01T16:00:14.626794Z 6 [Warning] Iteration 4: Current time obtained from system is greater than 2038
2038-02-01T16:00:14.626801Z 6 [Warning] Iteration 5: Current time obtained from system is greater than 2038
2038-02-01T16:00:14.626809Z 6 [ERROR] This MySQL server doesn't support dates later than 2038
2038-02-01T16:00:14.627757Z 0 [Note] Giving 2 client threads a chance to die gracefully
2038-02-01T16:00:14.627821Z 0 [Note] Shutting down slave threads
2038-02-01T16:00:16.627925Z 0 [Note] Forcefully disconnecting 2 remaining clients

启动最新的mysql 8 ：

docker run -itd -p 3306:3306 -e MYSQL_ROOT_PASSWORD=root -v /data/mysql:/var/lib/mysql --name mysql mysql:debian# 设置密码root
# 设置存储文件在/data/mysql 目录才可以启动成功。

创建数据库和表：


CREATE DATABASE demo DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; CREATE TABLE `test_time` (`id` bigint(16) NOT NULL PRIMARY KEY AUTO_INCREMENT COMMENT '主键',`time1` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',`update_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间') ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='测试时间表';

然后插入下，确实插入有问题了。

mysql>   insert into sys_test(id,time1) values (1, now());
ERROR 1292 (22007): Incorrect datetime value: '2038-02-01 16:00:45' for column 'time1' at row 1
mysql>

但是进行查询的时候：

mysql> SELECT FROM_UNIXTIME ( UNIX_TIMESTAMP() )-> ;
+------------------------------------+
| FROM_UNIXTIME ( UNIX_TIMESTAMP() ) |
+------------------------------------+
| 2038-02-01 16:05:20                |
+------------------------------------+
1 row in set (0.00 sec)mysql> select UNIX_TIMESTAMP();
+------------------+
| UNIX_TIMESTAMP() |
+------------------+
|       2148653589 |
+------------------+
1 row in set (0.00 sec)mysql> SELECT FROM_UNIXTIME ( 2147483647 )-> ;
+------------------------------+
| FROM_UNIXTIME ( 2147483647 ) |
+------------------------------+
| 2038-01-19 03:14:07          |
+------------------------------+
1 row in set (0.00 sec)

模拟的方式，首先使用最新的mysql 8 ，然后创建库和表，再插入数据。
重启 mysql 8 ，首先只有mysql 8 最新的是可以启动成功。其他的版本没有实验。

然而并没有出现查询出 1970 年的情况，没有溢出，说明数据库已经对时间戳进行升级，支持 2147483647 以上的数据了。

但是要是对数据库进行映射还是需要使用 long 型比较稳妥。
或者数据库直接换成 datetime 类型即可。

3，总结

所以在设计 mysql 数据表的时候还是要使用 datetime 比较好。
不要使用时间戳字段，虽然还有16年，以后用啥数据库都不知道了。
但是保险起见还是一次到位好，再有datetime 更直观，时间戳看的费劲。
还需要转换，太麻烦了。

本文的原文连接是:
https://blog.csdn.net/freewebsys/article/details/127455169

MySQL的时间戳2038年问题还有16年，最好在设计上的时候使用datetime就可以了，不要使用时间戳字段了，即使用了也不要用int类型进行映射，使用long类型映射即可相关推荐

mysql 2038年问题_当前系统在2038年之后datetime类也无法获取当前时间的解决
由于php 32位使用 int 类型保存时间戳,也就是从1970 00:00:00 到当前时间的秒数. 而32位int 数字的取值范围是 -2147483648 到 2147483647. 所以当时 ...
mysql 2038年问题_64位Ubuntu系统的时间戳，2038年问题
问题描述我正在使用64位Ubuntu系统. 我目前正在研究一个包含MariaDB的项目.我打算在项目中引入时间戳记技术,以便人们可以在不同时区获得正确的时间. 我已阅读并阅读了一些有关2038年问题 ...
mysql 2038年问题_时间戳（UnixTimestamp）与《2038年问题》
时间戳是从格林威治时间1970年01月01日00时00分00秒(北京时间1970年01月01日08时00分00秒)起至现在的总秒数. 现在时间戳的长度是十位(1435113975--2015/6/24 ...
ElasticSearch03_Mapping字段映射、常用类型、数据迁移、ik分词器、自定义分词器
文章目录 ①. Mapping字段映射概述 ②. 常用类型如下 - text.keyword ③. 映射中对时间类型详解 ④. ES的keyword的属性ignore_above ⑤. 映射的查看.创 ...
商城项目18_esMapping字段映射、常用类型、数据迁移、ik分词器、自定义分词器
文章目录 ①. Mapping字段映射概述 ②. 常用类型如下 - text.keyword ③. 映射中对时间类型详解 ④. ES的keyword的属性ignore_above ⑤. 映射的查看.创 ...
关于mysql时间超过2038年时间戳查询数据问题
问题复现: 有一个联表方案需要对接搜索组,根据活动的结束时间来查询数据,由于搜索组针对日期查询只能传long类型时间戳来比较,某一个长期活动数据明明在时间范围内,但是一直查询不出来, 问题分析: 后来 ...
【Protobuf协议】003-嵌套类型、更新一个消息类型、Any、Oneof、Map（映射）、包
目录七.嵌套类型八.更新一个消息类型九.Any 十.Oneof 1.概述 2.使用Oneof 3.Oneof 特色 4.向后兼容性问题十一.Map(映射) 1.概述 2.向后兼容性问题十二. ...
使用TypeScript映射和条件类型使React组件更出色
by Deepu K Sasidharan 通过Deepu K Sasidharan 使用TypeScript映射和条件类型使React组件更出色 (Make your React component ...
python映射类型-python第二版7章笔记--映射和集合类型
7.1 映射字典是 Python 语言中唯一的映射类型.映射类型对象里哈希值(键) 和指向的对象(值)是一对多的关系. 它们与 Perl 中的哈希类型(译者注:又称关联数组)相似,通常被认为是可变的 ...

MySQL的时间戳2038年问题还有16年，最好在设计上的时候使用datetime就可以了，不要使用时间戳字段了，即使用了也不要用int类型进行映射，使用long类型映射即可

目录

前言

1，关于MySQL时间戳的2038年BUG

2，使用Docker创建MySQL 模拟下

3，总结

MySQL的时间戳2038年问题还有16年，最好在设计上的时候使用datetime就可以了，不要使用时间戳字段了，即使用了也不要用int类型进行映射，使用long类型映射即可相关推荐

最新文章

热门文章