標籤:mysql
後台運營同事問我,有些同事實際打卡時間與資料庫打卡時間記錄的不一樣
mysql> select *,from_unixtime(create_time) from 表名 where source_id=xxx\G*************************** 1. row *************************** id: xxx uid: xxx source_id: xxx create_time: 1495324892 type: 0 source_status: 0 nick_name: 環境監控組-xxx start_time: 1495324883 remark: 忽略視頻 pre_check_status: 0 source: 3from_unixtime(create_time): 2017-05-21 00:01:321 row in set (0.00 sec)
因為運營庫是2主2從,我對比了主從的資料,發現確實不一樣,一個是早上8點,另外一個是淩晨,使用了from_unixtime函數,結果相差8個小時,比較像是時區的問題
mysql> select from_unixtime(1495324892);+---------------------------+| from_unixtime(1495324892) |+---------------------------+| 2017-05-21 08:01:32 |+---------------------------+1 row in set (0.00 sec)mysql> select from_unixtime(1495324892);+---------------------------+| from_unixtime(1495324892) |+---------------------------+| 2017-05-21 00:01:32 |+---------------------------+1 row in set (0.00 sec)
懷疑是linux機器的時區問題,但查詢發現都是一樣的
Thu May 25 15:11:29 CST 2017
既然與linux時區不轉換,那應該跟MySQL的時間有關了,再次分別查詢主從的時間
mysql> select now();+---------------------+| now() |+---------------------+| 2017-05-25 15:12:28 |+---------------------+1 row in set (0.00 sec)mysql> select now();+---------------------+| now() |+---------------------+| 2017-05-25 07:09:31 |+---------------------+1 row in set (0.00 sec)
果然是MySQL的時間問題
mysql> show variables like "%time_zone%";+------------------+--------+| Variable_name | Value |+------------------+--------+| system_time_zone | HKT || time_zone | SYSTEM |+------------------+--------+2 rows in set (0.00 sec)mysql> show variables like "%time_zone%";+------------------+--------+| Variable_name | Value |+------------------+--------+| system_time_zone | UTC || time_zone | SYSTEM |+------------------+--------+2 rows in set (0.00 sec)
發現一個MySQL處於UTC時間,世界標準時間,而另外一個是香港時間,中國是東八區,比世界標準時間多8個小時,這就解釋了為什麼8點打卡,卻顯示在淩晨上班。於是把有問題的MySQL,重新修改時區
set global time_zone = ‘+8:00‘;set time_zone = ‘+8:00‘;flush privileges;
本文出自 “DBA營運空間” 部落格,請務必保留此出處http://dadaman.blog.51cto.com/11373912/1929429
mysql問題 - timezone