我们在mysql客户端查询 now() 系统当前日期时间，会发现得到的结果比系统实际日期时间慢8个小时左右，这是由于不同的时区导致的
1、在 mysql 的服务端的 my.conf 文件中 [mysqld] 节点下设置时区参数
default-time-zone=Asia/Shanghai
2、如果 mysql 的版本是 5.7 配置如下参数
default-time-zone = '+8:00'
3、如果 mysql 服务是由 docker 创建的容器，需要查看 mysql 容器的系统日期是否正确，如果不正确，需要调整 mysql 容器内的系统日期时间
方式一：
//1、把当前宿主机的时区信息复制到mysql容器的时区中 docker cp /usr/share/zoneinfo/Asia/Shanghai 容器名称或Id:etc/localtime //2、重启mysql服务即可 docker restart 容器名称或Id
方式二：
共享主机的 localtime，创建容器的时候指定启动参数，挂载 localtime 文件到容器内
docker run --name 容器名称 -v /etc/localtime:/etc/localtime
如此，时区不一致的问题就解决了
服务器使用mysql 5.7数据库，线上运行程序时，保存时间相差14小时
首先以为是线上linux系统数据库时区问题，特地查看了线上linux数据库时区
Last login: Wed Nov 27 14:39:13 2019 from 192.168.2.147 [root@localhost ~]# date -R Thu, 28 Nov 2019 08:44:39 +0800 [root@localhost ~]# hwclock 2019年11月28日 星期四 08时44分52秒 -0.938419 秒 [root@localhost ~]#
检查时区后发现时区设置是正确的，怀疑是线上数据库时区设置问题，检查线上数据库时区设置
mysql> show variables like '%time_zone%'; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | CST | | time_zone | SYSTEM | +------------------+--------+ 2 rows in set (0.03 sec)
发现线上数据库时区设置也是一致，于是在本地重新运行程序，添加断点，监听时间传参变化，断点逐步进行，在保存至数据库前，断点中检查的时间都是正确的，可以确定是数据库时间保存时出现的问题。
在这个地方我自己遇到的问题更尴尬，排查问题时是在同事电脑上进行排查，检查了pom文件中依赖的mysql-connector-java 版本号是 5.1.46 ，运行时无报错信息，但实际打包项目时使用的是我电脑进行打包，但我电脑中pom文件里mysql-connector-java 版本号写的是runtime，也就是跟着springboot版本选择，我使用的springboot版本号是2.1.5，所以对应的mysql版本jar包文件是8.0的jar包，就是这个问题导致是时间相差了14小时，更改mysql版本号，重新运行，问题解决。
自己在排查问题过程中也发现了类似相关的数据库时间保存相差N小时问题主要出于几种情况：
到此这篇关于解决MySQL时区日期时差8个小时的问题的文章就介绍到这了,更多相关MySQL差8个小时内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
编程 | 2023-02-24 21:36
编程 | 2023-02-21 12:51
编程 | 2023-02-21 12:47
编程 | 2023-02-21 00:15
编程 | 2023-02-21 00:08
编程 | 2023-02-20 21:46
编程 | 2023-02-20 21:42
编程 | 2023-02-20 21:36
编程 | 2023-02-20 21:32
编程 | 2023-02-20 18:12
Python之列表推导式最全汇总(上篇)
加载中,请稍侯......
网友评论