mysql时区重启后失效_mysql时区问题

背景

插入timestamp类型与datetime类型数据比预计结果早14小时

原因

如果说相差8小时不够让人惊讶，那相差13小时可能会让很多人摸不着头脑。出现这个问题的原因是JDBC与MySQL对 “CST” 时区协商不一致。因为CST时区是一个很混乱的时区，有四种含义：美国中部时间 Central Standard Time (USA) UTC-05:00或UTC-06:00

澳大利亚中部时间 Central Standard Time (Australia) UTC+09:30

中国标准时 China Standard Time UTC+08:00

古巴标准时 Cuba Standard Time UTC-04:00

MySQL中，如果time_zone为默认的SYSTEM值，则时区会继承为系统时区CST，MySQL内部将其认为是UTC+08:00。而jdbc会将CST认为是美国中部时间，这就导致会相差13小时，如果处在冬令时还会相差14个小时。

解决方案

解决此问题的方法也很简单，我们可以明确指定MySQL数据库的时区，不使用引发误解的CST，可以将time_zone改为'+8:00'，同时jdbc连接串中也可以增加serverTimezone=Asia/Shanghai。

如何避免上述时区问题，可能你心里也有了些方法，简要总结几点如下：首先保证系统时区准确。

jdbc连接串中指定时区，并与数据库时区一致。

time_zone参数建议设置为'+8:00'，不使用容易误解的CST。

各环境数据库实例时区参数保持相同。

拓展知识

设置时区方法1

检查时区 show variables like '%time_zone%';

设置当前会话时区 set time_zone='+8:00'，只对本次会话有效，会话结束后，失效。

设置全局会话时区 set global time_zone='+8:00',永久有效

设置立即生效 flush privileges

设置时区方法2

通过修改配置文件，重启mysql后永久有效

https://www.cnblogs.com/jiadi...

数据库参数信息：

全局参数system_time_zone：

系统时区，在MySQL启动时会检查当前系统的时区并根据系统时区设置全局参数system_time_zone的值。

全局参数time_zone：

用来设置每个连接会话的时区，默认为system时，使用全局参数system_time_zone的值。

数据库连接参数：

serverTimeZone：

此参数设置时会选择time_zone ,为设置则使用数据库系统时区。