Mysql 数据库时间与系统时间不一致问题排查

NO.1 产生问题

在我们学习中使用到sysdate这个函数时，发现查出来的日期时间与当前的正确时间不一致，相差8个小时左右，为什么会产生这个问题？又该如何解决？

– 在数据库中使用sysdate()函数查询系统时间

select sysdate();

结果显示：

NO.2 原因分析

原因分析1：第一时间想到的是数据库所在的云服务器时间可能与网络时间不同步，因为数据库是装在云服务器上的，但是这种可能性应该较小，因为购买的阿里云服务器应该不会存在这种问题，一般会自动校对时间。于是先确定云服务器的时间，输入date命令查看云服务器系统时间，结果云服务器显示的时间是正确的，如下图：

原因分析2：排除第一种可能后，又想到Mysql是部署在云服务器的docker容器上的，会不会是docker容器时间不对呢？因此进入容器，查看容器的系统时间。

# 进入容器   d71f18f09a4e：容器id，以自己的容器id为准

docker exec -it d71f18f09a4e /bin/bash

# 查看系统时间

date

果然，容器的时间不对，跟正确的时间相差了8个小时，跟数据库查询的结果是一样的问题。所以SQL查出来的时间是跟随容器的系统时间一致的，因此存在同样的问题。所以我们只要把容器时间修改正确了，那我们通过SQL查询出来的时间不对的问题也就解决了。

NO.3 解决方法

1.通过sql语句，查看系统时区，修改时区来校对时间

– 第一步：查看系统时区

show variables like ‘%time_zone%’;

– 第二步：修改时区，并生效

– 修改系统时区

set global time_zone = ‘+08:00’;

– 修改当前会话时区

set time_zone = ‘+8:00’;

– 立马生效

flush privileges;

– 修改后再次查看

show variables like ‘%time_zone%’;

– 第三步：修改后再查看系统时间显示

select sysdate();

第一步：系统时区查询：

时区知识普及： 整个地球分为二十四时区，每个时区都有自己的本地时间。在国际无线电通信场合，为了统一起见，使用一个统一的时间，称为通用协调时(UTC, Universal Time Coordinated)。UTC与格林尼治平均时(GMT, Greenwich Mean Time)一样，都与英国伦敦的本地时相同。在本文中，UTC与GMT含义完全相同。北京时区是东八区，领先UTC八个小时，所以我们的时区为UTC+8。

第二步：修改时区，并生效：

第三步：修改后再查看系统时间：

2.在云服务器上，把云服务器的正确时间文件拷贝到容器的中去，校对容器的时间

# 将服务器上时间文件拷贝到容器  d71f18f09a4e：容器id，以自己的容器id为准

docker cp /usr/share/zoneinfo/Asia/Shanghai  d71f18f09a4e:/etc/localtime

# 重启容器

docker restart d71f18f09a4e

# 查看容器是否运行docker ps

# 进入容器   d71f18f09a4e：容器id，以自己的容器id为准

docker exec -it d71f18f09a4e /bin/bash

# 查看容器的时间

date

**第一步：**复制日志文件后，查看容器时间：

第二步：数据库查询时间：

注意：如果容器时间显示正确，但是数据库查询结果还是不对，则需要关闭客户端（navicat），重新打开后再次查询，基本就不会有问题了。

行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群： 786229024，里面有各种测试开发资料和技术可以一起交流哦。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取 【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

代码007普通

打赏 收藏 海报 链接