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

•  📢专注于分享软件测试干货内容，欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
• 📢交流讨论：欢迎加入我们一起学习！
• 📢资源分享：耗时200+小时精选的「软件测试」资料包
• 📢 软件测试学习教程推荐：火遍全网的《软件测试》教程

---

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），重新打开后再次查询，基本就不会有问题了。

---

最后我邀请你进入我们的软件测试学习交流群：785128166， 大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，还会有免费直播课，收获更多测试技巧，我们一起进阶Python自动化测试/测试开发，走向高薪之路

感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！