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),重新打开后再次查询,根本就不会有问题了。
感谢每一个认真阅读我文章的人!!!
作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些主动化测试的学习资源,希望能给你前进的路上带来帮助。
软件测试面试文档
我们学习一定是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,而且有字节大佬给出了权威的解答,刷完这一套面试资料信赖大家都能找到满意的工作。
视频文档获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋侪来说应该是最全面最完备的备战仓库,这个仓库也陪伴我走过了最艰巨的路程,希望也能帮助到你!以上均可以分享,点下方小卡片即可自行领取。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |