general_log

• 该表提供查询普通SQL语句的执行记录信息，用于查找客户端到底在服务端上执行了什么SQL（当然，还可以使用audit log审计插件记录，详见后续章节）

• 该表中的信息在SQL开始执行时就会进行记录，而不是等待SQL执行结束才记录

• 表结构定义

CREATE TABLE `general_log` (
  `event_time` timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
  `user_host` mediumtext NOT NULL,
  `thread_id` bigint(21) unsigned NOT NULL,
  `server_id` int(10) unsigned NOT NULL,
  `command_type` varchar(64) NOT NULL,
  `argument` mediumblob NOT NULL
) ENGINE=CSV DEFAULT CHARSET=utf8 COMMENT='General log';

• 表字段含义

• event_time：查询日志记录到表的那一刻的log_timestamps系统变量值，用于标记查询日志记录何时入库
• user_host：表示该查询日志记录的来源，其中有用户名和主机名信息
• thread_id：表示该查询日志记录执行时的process_id
• server_id：表示执行该查询的数据库实例ID
• command_type：表示该查询的command类型，通常都为query
• argument：表示执行查询的SQL语句文本

• 表记录内容示例

root@localhost : (none) 07:25:50> set global log_output='TABLE';
Query OK, 0 rows affected (0.00 sec)

root@localhost : (none) 07:26:20> set global general_log=1;       
Query OK, 0 rows affected (0.01 sec)

root@localhost : (none) 07:26:32> select * from mysql.general_log;
+----------------------------+---------------------------+-----------+-----------+--------------+---------------------------------+
| event_time | user_host | thread_id | server_id | command_type | argument |
+----------------------------+---------------------------+-----------+-----------+--------------+---------------------------------+
| 2018-06-19 19:26:32.891371 | root[root] @ localhost [] | 3 | 3306102 | Query | show databases |
| 2018-06-19 19:26:42.012064 | root[root] @ localhost [] | 3 | 3306102 | Query | select * from mysql.general_log |
+----------------------------+---------------------------+-----------+-----------+--------------+---------------------------------+
2 rows in set (0.00 sec)

root@localhost : (none) 07:26:42> select connection_id();
+-----------------+
| connection_id() |
+-----------------+
| 3 |
+-----------------+
1 row in set (0.00 sec)

• mysqld按照接收请求的顺序将语句写入查询日志中(这可能与它们的执行顺序不同）
• 在主从复制架构中

• 主库上在使用基于语句的日志格式时，从库在在重放这些语句之后，会把这些语句记录自己的查询日志中（需要从库启用了查询日志记录功能），使用语句格式记录的binlog在使用mysqlbinlog命令解析之后导入数据库中时，如果实例开启了查询日志记录功能，则这些解析语句也会被记录到查询日志中
• 主库上使用基于row日志格式时，从库重放这些数据变更之后，这些语句不会被计入从库的查询日志中
• 在主库上使用基于mixed日志格式时，如果主库是以语句格式记录的，则从库重放这些数据变更之后会把语句记录到自己的查询日志中（需要从库启用了查询日志记录功能），如果主库在记录binlog时被转换为了row格式，则也跟row格式复制一样，从库重放这些数据变更之后不会把这些语句记录到自己的查询日志中。

• 查询日志可以使用系统变量sql_log_off变量动态关闭当前会话或者所有会话的查询日志记录功能（与sql_log_bin系统变量的作用类似）
• 查询日志开关general_log变量和查询磁盘日志文件路径general_log_file变量都可以动态修改（如果已经有查询日志处于打开状态，则使用general_log_file变量修改查询日志路径时关闭旧的查询日志，打开新的查询日志），当启用查询日志时，查询日志将保持到系统变量log_output指定的目的地
• 如果启用了查询日志，则Server重新启动的时候会重新打开查询日志文件，如果查询日志存在，则直接重新打开，如果查询日志不存在，则重新创建，如果需要再Server运行时动态归档查询日志，则可以按照如下命令操作（linux或者unix平台）

shell> mv host_name.log host_name-old.log
shell> mysqladmin flush-logs
shell> mv host_name-old.log backup-directory
# 在Windows上，请直接使用重命名，而不是mv命令

• 也可以在Server运行时通过语句先关闭查询日志功能，然后使用外部命令来归档，然后再重新启用查询日志，这样就不需要使用flush-logs命令来刷新日志文件了，此方法适用于任何平台，命令如下：

SET GLOBAL general_log ='OFF';
# 在禁用日志的情况下，从外部重命名日志文件;例如，从命令行。然后再次启用日志：

SET GLOBAL general_log ='ON';
# 此方法适用于任何平台，不需要重新启动服务器。

• 默认情况下，在Server中执行的语句如果带了用户密码，会被Server重写该语句之后再写入到查询日志中，如果需要记录明文密码，则需要使用--low-raw选项启动Server(使用该选项会绕过密码重写功能)，通常不建议记录密码明文信息到查询日志中，因为不安全，但如果有必要，自行判断（例如：需要查询原始的语句信息来排查问题时）

• 如果带密码的语句中，指定了密码是一个hash值时，则密码字符串不会被重写，例如：CREATE USER 'user1'@'localhost' IDENTIFIED BY PASSWORD 'not-so-secret';就会被原本原因地记录下来，但是如果去掉PASSWORD关键字CREATE USER 'user1'@'localhost' IDENTIFIED BY 'not-so-secret';，则在查询日志中就会被重写为：CREATE USER 'user1'@'localhost' IDENTIFIED WITH 'mysql_native_password' AS '<secret>'

• 一些语法错误的SQL默认情况下也不会被记录到查询日志中，使用--low-raw选项启动Server会记录所有的原始SQL语句
• 查询日志表中的时间戳信息来源于系统变量log_timestamps（包括慢查询日志文件和错误日志文件中的时间戳都来自此系统变量的值），该时间戳值在查询时可以使用CONVERT_TZ（）函数或通过设置会话将从这些表中的时间戳信息从本地系统时区转换为任何所需时区（修改会话级别的time_zone变量值）

---

上一篇：日志表 |下一篇：slow_log表