关于mysql:mysql时区问题

8次阅读

共计 1476 个字符，预计需要花费 4 分钟才能阅读完成。

插入 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 , 为设置则应用数据库系统时区。

MySQL：datetime 与 timestamp 的区别及应用抉择
https://majing.io/posts/10000…
参考：
https://www.cnblogs.com/gaoga…
https://www.cnblogs.com/smile…
https://blog.csdn.net/qq_3110…
https://www.cnblogs.com/jiadi…
https://segmentfault.com/a/11…
https://www.zhetao.com/conten…
http://www.mamicode.com/info-…
https://www.cnblogs.com/july-…
https://blog.csdn.net/vae1314…
https://blog.csdn.net/weixin_…
https://www.cnblogs.com/kunji…

正文完