MySQL5.7慢查询日志时间与系统时间差8小时原因

在对慢查询进行查看的时候发现时间不对,正好与系统时间相差8个小时。
1、慢查询显示时间如下
# Time: 2020-01-10T06:42:24.940811Z

2、系统时间
$ date
Fri Jan 10 14:42:31 CST 2020

3、查看数据库参数
mysql> show variables like ‘log_timestamps‘;
+----------------+-------+
| Variable_name | Value |
+----------------+-------+
| log_timestamps | UTC |
+----------------+-------+
1 row in set (0.00 sec)

UTC大家都知道是世界统一时间,而我现在的系统时间是东八区,比UTC早了8个小时,这就对上了。查看官方文档看一下官网的解释。
log_timestamps

Property Value
Command-Line Format --log-timestamps=#
Introduced 5.7.2
System Variable log_timestamps
Scope Global
Dynamic Yes
Type Enumeration
Default Value UTC
Valid Values
UTC

SYSTEM

This variable controls the time zone of timestamps in messages written to the error log, and in general query log and slow query log messages written to files. It does not affect the time zone of general query log and slow query log messages written to tables (mysql.general_log, mysql.slow_log). Rows retrieved from those tables can be converted from the local system time zone to any desired time zone with CONVERT_TZ() or by setting the session time_zone system variable.

Permitted log_timestamps values are UTC (the default) and SYSTEM (local system time zone).

Timestamps are written using ISO 8601 / RFC 3339 format: YYYY-MM-DDThh:mm:ss.uuuuuu plus a tail value of Z signifying Zulu time (UTC) or ±hh:mm (an offset from UTC).

修改参数就可以解决问题。
mysql> SET GLOBAL log_timestamps = SYSTEM;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW GLOBAL VARIABLES LIKE ‘log_timestamps‘;
+----------------+--------+
| Variable_name | Value |
+----------------+--------+
| log_timestamps | SYSTEM |
+----------------+--------+

原文地址:https://blog.51cto.com/roidba/2465841

时间: 2024-10-12 08:32:01

MySQL5.7慢查询日志时间与系统时间差8小时原因的相关文章

django时间与系统时间差8小时

问题现象: 在用django做好的网站,发表文章后显示的发布时间比当前时间慢了8小时 查找问题: 查看服务器系统时间,经查与当前时间一致,无问题 查看数据库中的时间也一样 最终原因: 在settings文件中,设置了时区为TIME_ZONE = 'UTC',使程序执行时使用了UTC时区时间,所以比当前时间慢8小时,修改为TIME_ZONE = 'Asia/Shanghai'后,解决问题!

java获取的时间比系统时间差8小时

操作步骤:myeclipse中window(窗口)→Preferences(首选项)→java→Installed JREs→edit按钮→Default VM Arguments(缺省的vm参数)→" -Duser.timezone=Asia/Shanghai " → 保存. 记住,引号中前面的那个"-"不能少了. 现在,我们就完全搞定这个问题了.

mysql-5.7.10产生的日志时间与系统时间不一致

问题描述: 使用安装的mysql workbench登录mysql后,选择server log 进行日志查看的时候,发现产生日志的时间和当期的系统时间不一致:如下图: 查看mysql系统的当期时间显示的是: 出现如上情况,很是不解:于是在度娘上问了一下各路大神,发现还真有灵丹妙药可以用: 原因描述: 在MySQL 5.7 新增了 log_timestamps 这个参数,该参数主要是控制 error log.genera log,等等记录日志的显示时间参数 且默认安装后error_log,slow

mysql5.7日志时间与系统时间不一致

在MySQL 5.7.2 新增了 log_timestamps 这个参数,该参数主要是控制 error log.genera log,等等记录日志的显示时间参数且默认安装后error_log,slow_log 日志时间戳默认为UTC,因此会造成与系统时间不一致,与北京时间相差8个小时 mysql> SHOW GLOBAL VARIABLES LIKE 'log_timestamps'; +----------------+-------+ | Variable_name | Value | +-

告警日志时间与系统时间相差8小时

系统默认的log_timestamps为UTC,与linux系统时间相差8小时 解决方法: SET GLOBAL log_timestamps = SYSTEM;(立即生效,重启mysql服务,失效) 永久生效方法,在/etc/my.cnf中添加 log_timestamps=system 原文地址:https://www.cnblogs.com/tonnytangy/p/11966344.html

centos linux 系统上 log4j打印的时间与CST时间差8小时的解决方法

在启动参数上加上时区设置-Duser.timezone=GMT+08 java -jar -Duser.timezone=GMT+08 target/micservice_histclientsdataetl-1.0-SNAPSHOT-jar-with-dependencies.jar local

mysql 慢查询日志分析

mysql慢查询: 慢查询相关的变量 slow_query_log:该参数控制着慢查询的状态, 1表示开启状态 ,0 表示关闭状态 slow_query_log_file:慢查询日志路径 long_query_time:最大查询阀值,查询的时间超过这个值就视为慢查询并且将其记录到慢查询日志中,慢查询日志路径 通过slow_query_log_file 这个变量设置 log_queries_not_using_indexes:没有使用到索引的查询语句是否记录到慢查询日志中. log_slow_sl

MySQL 开启慢查询日志与普通日志

一.开启满查询日志 1.查看慢查询日志 SHOW VARIABLES LIKE '%slow%'; 2.开启慢查询日志 set GLOBAL slow_query_log =on; 3.设置慢查询日志保存文件与路径 set GLOBAL slow_query_log_file='/tmp/mysql_slow.log'; 4.设定慢查询日志时间 set GLOBAL long_query_time=1; 二.开启普通日志 1.查看普通日志 SHOW VARIABLES LIKE 'general

mysql5.6.20开启慢查询日志以及创建索引优化慢查询

[[email protected] ~]# egrep "slow_query_log*|long_query_time|slow-query-log-file" /usr/local/mysql5.6/my.cnf long_query_time = 1  (慢查询时间) slow_query_log=1 slow-query-log-file = /data/mysql3307/log/mysql-slow.log log_queries_not_using_indexes=1