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

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

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

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

Thu Oct 20 13:54:12 EDT 2016

时间确实不正确，设置下系统时间date -s "2016-10-20 14:41:31"

写入cmosclock -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即使重启时区和时间也是正确的。这也是永久性做法。