我最新的慢日誌去哪了？

最近接到一個客戶說，我在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 2017

MySQL的時間

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2017-07-06 10:36:10 |
+---------------------+
1 row in set (0.00 sec)

比較悲傷並沒有看到我們想看到的時間，時間都跟我螢幕右下方的時間相一致。

那問題出在哪裡了呢？到底是哪裡控制了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)

然後我看了一下我自己的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             |
+---------------------------------------+-------------------+

注：北美東部夏令時間英文名: Eastern Daylight Time 也就是上面的EDT

       北美中部夏令時間英文名: Central Daylight Time 也就是上面的CST

這個system_time_zone跟time_zone有什麼區別呢？這兩個引數是幹什麼的呢？

看一下官方文件的解釋：

也就是說這個引數才是真正的控制伺服器的區時，且在MySQL一旦執行，這個區時就是寫死了的，不會變。那麼也就是很有可能是由於這兩個引數的問題導致我的慢日誌的時間變慢了。來測試一下

啟動MySQL的時候指定timezone為CST

發現這個時候的MySQL系統時間慢了8個小時，而且慢日誌的時間跟這個時間是一致的，也是慢了8個小時。

./bin/mysqld_safe --defaults-file=/home/my3301/my.cnf --timezone=CST-8 &

啟動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.

也就是一個是伺服器系統時區，一個是連線的客戶端的時區。

如果這兩個引數設定不當，就會導致Linux主機系統的時間、MySQL select now()的時間，還有慢日誌等日誌產生的時間不一致。

這也就是為什麼客戶的慢日誌為啥只能收集到12小時“前”的原因了~