最近接到一个客户说，我在easydb中为什么看不到实时的慢sql，只能看到过气的慢日志的？
慢日志对于MySQL来说确实，是非常重要的，无论是问题排查还是性能优化，都能从其中捕获一些问题的来源，如果慢日志失去了实时性那还了得？
然后即刻登到easydb中去看，发现最新的慢日志定格在了7月5号晚22：00左右。难道真的是easydb捕获不到最新的慢日志了吗？
但是发现MySQL日志文件中的slowlog最后一条确实是跟easydb中的最新的一条相一致，那么easydb依旧是实时抓取slow log。那问题出现在哪里了呢？
Linux主机？还是MySQL服务器的时间？
Linux所在主机的时间
[root@msyql ]# date Thu Jul 6 10:35:12 CST 2017AI 代码解读
MySQL的时间
mysql> select now(); +---------------------+ | now() | +---------------------+ | 2017-07-06 10:36:10 | +---------------------+ 1 row in set (0.00 sec)AI 代码解读
比较悲伤并没有看到我们想看到的时间，时间都跟我屏幕右下方的时间相一致。
那问题出在哪里了呢？到底是哪里控制了MySQL slow日志里面的时间？
看一下关于MySQL 时间的参数
mysql> show variables like '%time%'; +---------------------------------+-------------------+ | Variable_name | Value | +---------------------------------+-------------------+ | binlog_max_flush_queue_time | 0 | | connect_timeout | 8 | | datetime_format | %Y-%m-%d %H:%i:%s | | delayed_insert_timeout | 300 | | explicit_defaults_for_timestamp | ON | | flush_time | 0 | | innodb_flush_log_at_timeout | 1 | | innodb_lock_wait_timeout | 5 | | innodb_old_blocks_time | 1000 | | innodb_rollback_on_timeout | OFF | | interactive_timeout | 28800 | | lc_time_names | en_US | | lock_wait_timeout | 31536000 | | long_query_time | 1.000000 | | net_read_timeout | 30 | | net_write_timeout | 60 | | rpl_stop_slave_timeout | 300 | | slave_net_timeout | 30 | | slow_launch_time | 2 | | time_format | %H:%i:%s | | timed_mutexes | OFF | | timestamp | 1499328877.100398 | | wait_timeout | 28800 | +---------------------------------+-------------------+ 25 rows in set (0.00 sec)AI 代码解读
然后我看了一下我自己的MySQL 关于时间的参数
mysql> show variables like '%time%'; +---------------------------------------+-------------------+ | Variable_name | Value | +---------------------------------------+-------------------+ | connect_timeout | 10 | | datetime_format | %Y-%m-%d %H:%i:%s | | delayed_insert_timeout | 302 | | flush_time | 0 | | have_response_time_distribution | YES | | innodb_lock_wait_timeout | 50 | | innodb_old_blocks_time | 0 | | innodb_rollback_on_timeout | OFF | | innodb_thread_concurrency_timer_based | OFF | | interactive_timeout | 7200 | | lc_time_names | en_US | | lock_wait_timeout | 31536000 | | long_query_time | 1.000000 | | net_read_timeout | 30 | | net_write_timeout | 60 | | query_response_time_range_base | 10 | | query_response_time_stats | OFF | | rpl_semi_sync_master_timeout | 1000 | | slave_net_timeout | 60 | | slow_launch_time | 2 | | slow_query_log_timestamp_always | OFF | | slow_query_log_timestamp_precision | second | | time_format | %H:%i:%s | | timed_mutexes | OFF | | timestamp | 1499329112 | | trx_changes_idle_timeout | 0 | | trx_idle_timeout | 0 | | trx_readonly_idle_timeout | 0 | | wait_timeout | 86400 | +---------------------------------------+-------------------+AI 代码解读
注：北美东部夏令时间英文名: Eastern Daylight Time 也就是上面的EDT
北美中部夏令时间英文名: Central Daylight Time 也就是上面的CST
这个system_time_zone跟time_zone有什么区别呢？这两个参数是干什么的呢？
看一下官方文档的解释：
发现这个时候的MySQL系统时间慢了8个小时，而且慢日志的时间跟这个时间是一致的，也是慢了8个小时。
./bin/mysqld_safe --defaults-file=/home/my3301/my.cnf --timezone=CST-8 &AI 代码解读
启动MySQL的时候指定timezone为CST-8
发现这个时候的MySQL系统时间跟我左下角的时间就正好吻合了，并且慢日志的时间跟我左下角的时间一致了。
这其实就验证了timezone这个参数影响了慢日志写入到日志里面的时间了。
那system_time_zone根time_zone又有什么区别呢？
The system_time_zone variable differs from time_zone. Although they might have the same value, the latter variable is used to initialize the time zone for each client that connects.AI 代码解读
也就是一个是服务器系统时区，一个是连接的客户端的时区。
如果这两个参数设置不当，就会导致Linux主机系统的时间、MySQL select now()的时间，还有慢日志等日志产生的时间不一致。
这也就是为什么客户的慢日志为啥只能收集到12小时“前”的原因了~
