MySQL的日志 - general log

微信搜索『coder-home』,或者扫一扫右侧的二维码,关注『程序猿集锦』。
了解更多干货分享,还有各类视频教程。
扫描它,带走我。

前言

前面的文章中我们介绍了slow query log慢查询日志、binlog二进制日志、relaylog中继日志、redolog重做日志、undolog回滚日志。今天我们来了解一下general log一般日志,有时候也叫做通用、普通、日志。

general log

在默认情况下,MySQL是不会打开general log的,这个log里面会记录MySQL所有的SQL语句,不管是查询语句,还是DML语句,还是DDL语句,还是DCL语句,这些语句统统都会被记录在general log文件中。就连我们连接和断开MySQL数据库的这些语句。

MySQL会把它收到的所有SQL语句按照接收的顺序依次记录在general log中。我们需要注意的是,这里接受的SQL语句的顺序,并不等于SQL语句就是按照这个接受的顺序来执行,因为有的时候,一些SQL可能需要等待其他锁被释放后才会被真正的执行,SQL语句的执行顺序是和binlog中的顺序是相匹配的。

假如我们执行一个select查询语句,在binlog中不会记录这样的SQL语句,但是在general log中就会记录这个select查询语句。

General log默认不开启的原因有两个:

  • 日志将会非常大,对磁盘是一个很大的压力。因为所有的操作都会被记录下来。
  • 对MySQL数据的性能有一定的影响。

所以,我们一般不会开启这个general log记录的功能,只有在排查某些错误的时候,才会临时打开一下,等到debug完成之后,再把它关闭。

如何开启 general log

如果在配置文件中永久开启:

[mysqld]
general_log=1
general_log_file=mysql_general_log.log
log_output=/var/lib/mysql

在SQL命令行中临时开启:

mysql> show variables like 'general_log'; -- 查看日志是否开启
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| general_log   | OFF   |
+---------------+-------+
1 row in set (0.02 sec)

mysql>
mysql> show variables like 'general_log_file'; -- 看看日志文件保存位置
+------------------+-------------------------+
| Variable_name    | Value                   |
+------------------+-------------------------+
| general_log_file | /var/lib/mysql/test.log |
+------------------+-------------------------+
1 row in set (0.02 sec)

mysql>
mysql> show variables like 'log_output'; -- 看看日志输出类型 table或file
+---------------+------------+
| Variable_name | Value      |
+---------------+------------+
| log_output    | FILE,TABLE |
+---------------+------------+
1 row in set (0.01 sec)

general log的参数

general log的参数主要有以下几个:

  • genral_log:用于控制是否开启general log。等于0表示关闭,等于1表示开启。默认是0
  • general_log_file:general log日志的文件名是什么,如果不配置这个参数的话,默认会以MySQL服务器的hostname作为general log日志的文件名称,具体文件为:<hostname>.log,general log日志的存放路径。如果不指定,则默认放在datadir参数所指定的目录下。也可以在这个参数中指定具体的路径+名称。
  • log_output:general log输出的方式,是输出表中,还是保存到文件中。这个参数的取值范围为:table,或者file。默认是保存到file文件中。这个参数是和慢查询日志是共用的,慢查询的日志是记录在表中还是只记录在文件中,也是用这个参数来控制。如果配置为table,就会把慢查询日志和general log日志都写在mysql.geneal_log表中。如果这个参数配置为table,file则表示即写入表中,也写入日志文件中,两个地方都写入日志。

在开启了general log的前提下,如果在某个session连接中,不想让此次操作的所有SQL被记录在general log中,则可以在session中执行set session sql_log_off=on就可以关闭当前session的操作被记录在general log中。

general log开启示例

接下里我们会针对开启general log做两个实验:

  1. 在命令行中,通过命令暂时开启。这种开启方式,在MySQL实例被重启的以后,会失效。
  2. 在配置文件中,配置参数开启。这种开启方式,永久生效,即便MySQL实例重启后,仍然有效。

通过命令暂时开启

我们来开启general log感受一下,下面我们登录到MySQL的命令行窗口,使用set global general_log=on;命令来开启。开启过程如下所示:

mysql> set session general_log=on; -- 这是一个全局参数,不能只针对当前session启用。
ERROR 1229 (HY000): Variable 'general_log' is a GLOBAL variable and should be set with SET GLOBAL
mysql> set global general_log=on; -- 对全局开启general log
Query OK, 0 rows affected (0.03 sec)

因为我的log_output参数配置的是FILE,TABLE,所以我的general log会记录在两个地方,一个是general log日志文件,一个是表中。日志保持方式的参数配置如下所示:

mysql> show variables like 'log_output';
+---------------+------------+
| Variable_name | Value      |
+---------------+------------+
| log_output    | FILE,TABLE |
+---------------+------------+
1 row in set (0.02 sec)

查看general log文件中的日志,当log_output参数有FILE的时候,general log日志文件的目录默认在datadir目录下面。前面我们开启general log的时候,因为没有显示的去指定general log日志的文件目录和文件名称,所以它默认是存放在datadir目录下,文件名称为<主机名称>.log。我可以看到在datadir目录下面如下日志:

root@test:/var/lib/mysql# pwd
/var/lib/mysql
root@test:/var/lib/mysql# ls -lstr *.log
8 -rw-r----- 1 mysql mysql 6293 Jan 13 15:40 test-slow.log
4 -rw-r----- 1 mysql mysql 2589 Jan 13 15:50 test.log
root@test:/var/lib/mysql# hostname
test.mysql
root@test:/var/lib/mysql#

我们来看下这个日志文件中的内容是什么,具体如下所示,可以看出所有的查询语句都会被记录在general log日志中。即便是查询语句也会被记录在里面。
在这里插入图片描述

上面我们看了general log日志文件中的内容,我们的配置还要去记录日志到表中,具体是记录在mysql.general_log表中。我们看下这个表中记录的内容。使用下面的SQL语句来查看表中的内容。

select 
	event_time,user_host,thread_id,server_id,command_type,
	convert(argument using utf8mb4) as sql_text 
from general_log limit 100;

在这里插入图片描述

通过配置文件永久开启

上面我们是通过set命令参数来开启的general log,下面我们采用在配置文件中配置general log日志文件参数的方式来开启。在使用配置文件来开启之前,我们先把前面我们使用set命令开启的操作给修改回去,然后再去修改配置文件来开启general log日志文件。先用下面的命令改回去。

mysql> set global general_log=off;
Query OK, 0 rows affected (0.02 sec)

改回去之后,我们再去看下日志文件中的内容。
在这里插入图片描述

我们在my.cnf配置文件中配置的具体参数如下,为了测试,我把general log日志文件路径和名称都修改一下。看下效果如何。修改完成如下参数后,重启MySQL服务。

[mysqld]
# 一般日志的开启
general_log=1
general_log_file=/tmp/mysql_general_log.log

这里顺便说一下,我的MySQL实例是用docker启动的一个容器镜像。用docker启动MySQL示例,兼职不要太方便,把参数配置文件挂载到本地,随便怎么修改参数文件,然后直接一个docker restart <容器名称或容器id>,直接搞定。在以后介绍一下关于docker的一些基本使用。

重启MySQL示例之后,啥都不做,直接去MySQL的/tmp下面看是否有mysql_general_log.log文件生成。检查结果如下,可以看到已经有general log文件生成。

root@test:/tmp# pwd
/tmp
root@test:/tmp# ls
mysql_general_log.log
root@test:/tmp# more mysql_general_log.log
mysqld, Version: 5.7.24-log (MySQL Community Server (GPL)). started with:
Tcp port: 0  Unix socket: /var/run/mysqld/mysqld.sock
Time                 Id Command    Argument
root@test:/tmp#

接下来,我们来执行一些SQL,看下日志是否可以正常记录在/tmp/mysql_general_log.log文件中,验证过程如下所示:
在这里插入图片描述

去看下mysql.genenal_log表中是否也会正常记录,检查结果如下:
在这里插入图片描述

关闭general log

在关闭general log的时候,我们只要把对应的配置在配置文件中删除或使用#注释掉或者删除掉,在修改完配置文件之后,然后再MySQL的命令行中,执行set global general_log=off;命令就可以马上关闭general log记录的功能,因为我们已经修改过配置文件,所以即便是MySQL重启之后,general log也不会开启了。

注意:如果只是修改了配置文件,但是没有在命令行中使用set命令关闭general log,重启MySQL实例之后,general log仍然处于开启状态。所以,即便是修改了配置文件,也要使用set global general_log=off命令关闭日志才可以。

如果我们只是通过set命令的方式去开启的,没有去修改配置文件。那么我们只需使用set命令的方式关闭即可了,不用去动配置文件了。在真正的debug错误的时候,推荐使用这种set命令的方式去临时开启和关闭general log日志,而不用去修改my.cnf配置文件。

清理general log文件

开启general log之后,日志文件会增长得很快,如果我们需要清理历史的general log文件,我们该怎么做?

  1. 如果是记录在文件中,使用cp命令,把general log日志文件备份一下(如果你确定这些历史的general log不在需要,那么可以不执行备份的这一步操作),然后使用管道命令把文件内容清空。操作大致如下:

    cp mysql_general_log.log mysql_general_log.log.bak
    echo "" > mysql_general_log.log
    

    **注意:**切记不要直接删除这个日志文件,否则这个文件不会自动生成,除非你重启MySQL数据实例。如果删除后,即便是你手动创建一个一样名称的日志文件,MySQL也不会把general日志记录进去。所以,我们只能在MySQL自己生成的文件中进行编辑,删除里面的内容。

    对于我们备份生产的文件mysql_general_log.log.bak,如果有必要留存,就拷贝到其他服务器或者其他归档存储中。如果没有必要留存,那么直接rm删除这个bak的log文件就可以了。

  2. 如果是记录在表中。先使用create table xx as select命令备份个表(如果你确认不需要历史的general log,那么你可以不执行备份操作)。然后,执行truncate命令删除表中数据。操作大致如下:

    create table mysql.general_log_bak as select * from mysql.general_log;
    truncate table mysql.general_log; -- 注意:这个表只能执行select或者truncate,没有insert,update,delete权限来操作。慢查询日志的中mysq.slow_log也是这权限。
    

    对于我们创建的备份表mysql.general_log_bak,如果日志内容有必要留存,那么把这个表使用mysqldump备份出来然后归档存放,如果没有必要留存,那么直接drop删除这个bak的表就可以了。

总结

一般情况我们不会开启general log日志,因为它的增长速度太快了。磁盘很快就会被占用完了。所以一般只有在需要debug一些特别难找的bug的时候,才会使用set global general_log=on开启,在生产我们需要的debug日志以后,就直接使用set global general_log=off关闭了。这里面的日志记录很详细,在排查一下比较隐蔽的问题的时候,还是可以提供很多有用的信息的。

MySQL的general log就分享到这里了。后面我会分享关于MySQL的最后一个日志:error错误日志。

微信搜索『coder-home』,或者扫一扫右侧的二维码,关注『程序猿集锦』。
了解更多干货分享,还有各类视频教程。
扫描它,带走我。
<think> 首先,用户的问题是:“我想了解mysql中ADMIN-PC是什么日志 请问mysql中ADMIN-PC日志的含义”。用户询问的是MySQL中的ADMIN-PC日志是什么。 我需要回顾提供的引用,因为它们可能包含相关信息。引用如下: - 引用[1]:谈论二进制日志(Binary Log),包括配置、备份等。 - 引用[2]:展示如何配置二进制日志,包括server-id和log-bin设置。 - 引用[3]:讨论ELK栈用于日志管理。 - 引用[4]:似乎是关于卸载MySQL的脚本,删除目录。 在这些引用中,没有直接提到“ADMIN-PC”这个词。用户可能在问一个特定的日志文件或概念,但引用中没有涉及。 用户提到“参考站内引用”,所以我应该尽量参考它们。然而,引用中没有ADMIN-PC的信息。 ADMIN-PC可能是一个自定义的名称。在MySQL上下文中,日志文件通常包括: - 错误日志(Error Log- 二进制日志(Binary Log- 慢查询日志(Slow Query Log- 通用查询日志General Query Log) 这些日志文件通常是基于配置命名的。引用[2]中提到了log-bin配置为/usr/local/mysql/data/mysql-bin,这会在data目录下创建像mysql-bin.000001这样的文件。 在Windows系统中,MySQL日志文件可能包含主机名,比如如果主机名是ADMIN-PC,日志文件可能被命名为类似mysql-bin.000001的文件,但通常不以主机名作为日志名称的一部分。 “ADMIN-PC”听起来像是一个Windows主机名。在MySQL中,日志文件的具体路径和名称取决于配置。例如,错误日志可能是一个文件如mysqld.log或error.log。 用户可能误以为ADMIN-PC是某个日志的类型,但基于标准MySQL日志,没有叫做“ADMIN-PC日志”的特定日志。 我的回答需要基于知识: - ADMIN-PC可能是指日志文件存储在名为ADMIN-PC的计算机上,或者是日志文件名称的一部分。 - 在引用中,没有直接的匹配。我应该解释可能的含义。 从系统级指令: - 所有行内数学表达式用$...$格式(但这里可能不涉及数学)。 - 独立公式用$$...$$(同样,可能不适用)。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 回答中引用的段落末尾自然地添加引用标识。 用户说:“上述引用仅供参考,并不是用户真正的需求”,所以我不能完全依赖引用。 用户的历史问题:用户上一次的问题似乎是关于MySQL日志通用问题,但这里是新问题。 在回复中,我需要: 1. 回答用户的查询:解释ADMIN-PC日志的含义。 2. 结构清晰,逐步解决问题。 3. 尽量真实可靠。 可能的解释: - ADMIN-PC很可能是一个主机名。在MySQL错误日志或二进制日志中,主机名可能被记录,但日志本身不是以主机名命名的。 - 在Windows上,MySQL安装默认目录可能包含主机名,但日志文件通常在配置的路径下。 - 在慢查询日志或二进制日志中,条目可能包含客户端主机信息,但日志不是叫做“ADMIN-PC日志”。 所以,我应该这样回答: - 澄清在MySQL中没有专门的“ADMIN-PC日志”。 - 解释ADMIN-PC可能指的是日志文件存储在主机名为ADMIN-PC的服务器上。 - 建议检查具体的日志配置。 参考引用: - 引用[1]提到二进制日志是核心日志- 引用[2]显示日志配置路径。 我可以提及二进制日志作为例子。 回答结构: 1. 直接回答:解释ADMIN-PC的含义。 2. 逐步说明MySQL日志的类型。 3. 建议如何确认。 最后,生成相关问题。 使用中文。 添加引用标识:如果在回答中引用引用中的内容,添加[^n]。 例如,如果提到二进制日志,参考引用[1]。 完整回答大纲: - 开头:在MySQL中,没有专门的“ADMIN-PC日志”。这可能是误解。 - 解释:ADMIN-PC可能是一个主机名。在MySQL日志中,主机名可能出现在日志条目中或日志文件路径中。 - 描述标准MySQL日志类型:错误日志、二进制日志、慢查询日志等。 - 参考引用[1]和[2]来讨论二进制日志配置。 - 建议用户检查MySQL日志文件的实际位置和内容。 - 结束:生成相关问题。 相关问题可能涉及MySQL日志管理。 </think> ### MySQL 中 ADMIN-PC 日志的含义解析 在 MySQL 数据库中,"ADMIN-PC" 并非一个标准的日志类型或专用术语。MySQL日志系统主要包括错误日志(Error Log)、二进制日志(Binary Log)、慢查询日志(Slow Query Log)等核心组件,日志文件的名称和内容通常由配置决定,而非特定主机名命名。下面我将逐步解释 "ADMIN-PC" 的可能含义,并基于 MySQL 标准日志机制给出清晰说明。 #### 1. **ADMIN-PC 的常见解释** - **主机名标识**:在大多数情况下,"ADMIN-PC" 指的是运行 MySQL 服务器的计算机主机名(例如,在 Windows 系统中,主机名可能设置为 "ADMIN-PC")。在 MySQL 日志中: - 日志文件本身不会直接命名为 "ADMIN-PC.log",但日志条目或文件路径可能包含主机名作为标识。 - 例如,错误日志(Error Log)或二进制日志(Binary Log)在写入时,可能会在条目中记录客户端或服务器的 hostname 信息(如连接来源的主机名),以帮助故障排查。 - **日志文件路径**:如果 MySQL 配置了自定义日志路径,日志文件可能存储在主机名为 "ADMIN-PC" 的特定目录下。例如,在引用[2]中提到的二进制日志配置: ``` log-bin = /usr/local/mysql/data/mysql-bin ``` 这会在 `/usr/local/mysql/data/` 路径下生成类似 `mysql-bin.000001` 的文件;如果服务器主机名是 "ADMIN-PC",实际文件路径可能类似 `C:\MySQL\data\ADMIN-PC-bin.000001`(在 Windows 系统),但这不是一个独立日志类型,而是文件命名的一部分[^2]。 - **潜在误解**:用户可能误将日志文件路径或日志内容中包含的 hostname 视为一个独立的日志类型。MySQL 没有名为 "ADMIN-PC日志" 的内置日志;它更可能是上下文相关的引用,比如在慢查询日志中记录客户端主机为 "ADMIN-PC" 的查询语句。 #### 2. **MySQL 标准日志类型回顾** ADM-PC 不是一个日志分类,但理解 MySQL 的标准日志有助于澄清: - **错误日志(Error Log)**:记录 MySQL 服务器的启动、关闭、运行时错误等关键事件。文件通常命名为 `hostname.err`(例如,`ADMIN-PC.err`),其中 "hostname" 会被替换为实际主机名。这是故障排查的首选日志[^1]。 - **二进制日志(Binary Log)**:用于复制和数据恢复,记录所有数据更改操作(如 INSERT、UPDATE)。配置中可指定路径和前缀(如引用[2]中的 `log-bin`),文件可能包含主机名作为前缀的一部分,但不是强制要求[^1][^2]。 - **慢查询日志(Slow Query Log)**:记录执行时间超过阈值(由 `long_query_time` 定义)的查询。日志条目中可能包含客户端主机名(如 `User@ADMIN-PC`),帮助分析性能瓶颈[^1]。 - **其他日志**:通用查询日志General Query Log)记录所有 SQL 语句,审计日志记录安全事件等。所有日志的命名和内容都可能涉及主机名,但本质上是基于配置的衍生。 #### 3. **如何确认 ADMIN-PC 在日志中的角色** 如果 "ADMIN-PC" 出现在您的环境中,建议通过以下步骤验证: - **检查日志配置**:登录 MySQL 服务器,查看配置文件(如 `my.cnf` 或 `my.ini`)。例如,在引用[2]中,通过编辑 `/etc/my.cnf` 设置 `log-bin` 和 `server-id`,这些参数决定了日志文件的位置和格式[^2]。运行命令: ```sql SHOW VARIABLES LIKE '%log%'; -- 查看所有日志相关设置 ``` 确认日志路径是否包含主机名(如 `datadir` 变量)。 - **查看日志文件**:在文件系统中检查日志目录(通常是 MySQL 的 `data` 目录)。例如: - 错误日志文件路径可通过 `SHOW VARIABLES LIKE 'log_error';` 获取。 - 如果主机名是 "ADMIN-PC",文件可能命名为 `ADMIN-PC-bin.000001` 或 `ADMIN-PC-slow.log`。 - **分析日志内容**:打开日志文件,搜索 "ADMIN-PC" 字符串。例如,在慢查询日志中,您可能看到类似条目: ``` # Time: 2023-10-05T08:00:00.000000Z # User@Host: root[root] @ ADMIN-PC [192.168.1.100] -- 这里显示了客户端主机名 Query_time: 5.000000 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 1000 SET timestamp=1696507200; SELECT * FROM large_table; ``` 这表示查询来自主机名为 "ADMIN-PC" 的客户端。 - **建议行动**:如果 "ADMIN-PC" 是您的服务器主机名,确保日志配置合理(如引用[1]强调的使用 ROW 格式和 GTID 模式以提高安全性)[^1]。如果它是外部主机名,检查网络连接或复制设置,避免安全隐患。 #### 4. **最佳实践参考** 在生产环境中,日志管理至关重要。引用[1]指出,二进制日志MySQL 最核心的日志之一,合理配置(如设置 `expire_logs_days` 和 `max_binlog_size`)能保障数据安全和系统稳定性[^1][^2]。引用[3]还提到,通过集中化日志分析(如 ELK 栈),可以提升可维护性和监控能力[^3]。这适用于所有类型的日志,包括可能与 "ADMIN-PC" 相关的日志文件。 ### 相关问题 1. 如何在 MySQL 中配置日志文件路径以包含主机名? 2. MySQL 错误日志的常见错误类型和排查方法有哪些? 3. 如何使用慢查询日志优化 MySQL 性能? 4. 在 Windows 系统中,MySQL 日志管理有哪些特殊注意事项? 5. 如何通过 ELK 栈实现 MySQL 日志的集中监控和分析?[^3]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值