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 解决方法
通过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。
第二步：修改时区，并生效：
第三步：修改后再查看系统时间：
在云服务器上，把云服务器的正确时间文件拷贝到容器的中去，校对容器的时间
# 将服务器上时间文件拷贝到容器 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），重新打开后再次查询，基本就不会有问题了。
资源分享【这份资料必须领取~】
下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】
来源地址：https://blog.csdn.net/m0_67695717/article/details/128345990
