运营那边说，后台获取的数据，时间都不准确了，立马找到运维这边，程序那边也给我这边提供了一个线索，就是在mysql里面执行了

SELECT from_unixtime(1476883657);

显示的时间并不是北京时间。因为最近刚把mysql搬到了香港，需要都按照北京时间来设置服务器时间。

先看了下服务器的系统时间

date
Thu Oct 20 13:54:12 EDT 2016

时间确实不正确，设置下系统时间

date -s "2016-10-20 14:41:31"

写入cmos

clock -w

以为这就完事了，再到数据库里面查看一下，

>SELECT from_unixtime(1476883657);

显示的时间还是不对，

>select now();

查看数据库当前时间，也是不正确的，这是为啥了

后来定睛一看，原来时区有问题。那么要修改一下系统时区

cp  /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
cp: overwrite `/etc/localtime’? y

再在服务器上查看一下

date
Thu Oct 20 13:54:12 CST 2016

ok了，时区变成了CST了，而不是之前的EDT；现在服务器的系统时间和时区都对了，再到mysql里面查看一下当前时间和时间戳显示正确与否。

查看当前时间：

>select now(); 或者>select sysdate()

>SELECT from_unixtime(1476883657);

还是有问题，那么分析下来，应该就是mysql的时区问题了

>show variables like "%time_zone%";
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | EDT    |
| time_zone        | SYSTEM |
+------------------+--------+
2 rows in set (0.00 sec)

#time_zone说明mysql使用system的时区，system_time_zone说明system使用EDT时区

果然mysql的时区没有改过来，表明mysql使用的是之前的系统时区，需要重启一下才能解决这个问题，当时线上业务怎么能轻易重启，那么就要使用临时的方法。

> set global time_zone = ‘+8:00‘;  ##修改mysql全局时区为北京时间，即我们所在的东8区
> set time_zone = ‘+8:00‘;  ##修改当前会话时区
> flush privileges;  #立即生效

好了，再来看看mysql的时区问题

>show variables like "%time_zone%";
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | EDT    |
| time_zone        | +08:00 |
+------------------+--------+
2 rows in set (0.00 sec)

再来试试时间戳，ok，因为数据库里面都是以时间戳来存储的，所以修改了mysql的时区和系统的时间、时区后顺利地解决了问题。

这里值得考虑的是，因为系统的时区修改了，时间也修改了，并且写入了CMOS，那么即使服务器重启，时间和时区也都是正确的，而mysql也需要重启才能读取到系统的最新时区，既然系统时区和时间都是正确的，那么mysql即使重启时区和时间也是正确的。这也是永久性做法。

本文出自 “郑小明的技术博客” 博客，请务必保留此出处http://zhengmingjing.blog.51cto.com/1587142/1863930

服务器时间和时区错误引起的mysql数据统计出错