mysql binlog一篇上手

╰半夏微凉° 2022-10-05 12:57 356阅读 0赞

# MySQL中一般有以下几种日志： #

<table style="width:500px;"> 
 <thead> 
  <tr> 
   <th>日志类型</th> 
   <th>写入日志的信息</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>错误日志</td> 
   <td>记录在启动，运行或停止mysqld时遇到的问题</td> 
  </tr> 
  <tr> 
   <td>通用查询日志</td> 
   <td>记录建立的客户端连接和执行的语句</td> 
  </tr> 
  <tr> 
   <td>二进制日志（binlog）</td> 
   <td>记录更改数据的语句</td> 
  </tr> 
  <tr> 
   <td>中继日志</td> 
   <td>从复制主服务器接收的数据更改</td> 
  </tr> 
  <tr> 
   <td>慢查询日志</td> 
   <td>记录所有执行时间超过 long_query_time 秒的所有查询或不使用索引的查询</td> 
  </tr> 
  <tr> 
   <td>DDL日志（元数据日志）</td> 
   <td style="text-align:left;vertical-align:middle;width:250px;">元数据操作由DDL语句执行</td> 
  </tr> 
 </tbody> 
</table>

--------------------

# 本文主要介绍二进制日志 binlog。 #

MySQL 的二进制日志 binlog 可以说是 MySQL 最重要的日志，它记录了所有的 DDL 和 DML 语句（除了数据查询语句select、show等），以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。binlog 的主要目的是复制和恢复。

Binlog日志的两个最重要的使用场景

**MySQL主从复制**：MySQL Replication在Master端开启binlog，Master把它的二进制日志传递给slaves来达到master-slave数据一致的目的  
**数据恢复**：通过使用 mysqlbinlog工具来使恢复数据

--------------------

# 本文使用到的mysql版本 #

![20210609141904650.png][]

一般来说开启binlog日志大概会有1%的性能损耗。

启用binlog，通过配置 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf 配置文件的 log-bin 选项：

在配置文件中加入 log-bin 配置，表示启用binlog，如果没有给定值，写成 log-bin=，则默认名称为主机名。（注：名称若带有小数点，则只取第一个小数点前的部分作为名称）

--------------------

# binlog日志包括两类文件: #

*  二进制日志索引文件（文件名后缀为.index）用于记录所有有效的的二进制文件
 *  二进制日志文件（文件名后缀为.00000\*）记录数据库所有的DDL和DML语句事件

--------------------

# 当遇到以下3种情况时，MySQL会重新生成一个新的日志文件，文件序号递增： #

*  MySQL服务器停止或重启时；
 *  使用 flush logs 命令；
 *  当 binlog 文件大小超过 max\_binlog\_size 变量的值时；

--------------------

# Binlog 的日志格式 #

记录在二进制日志中的事件的格式取决于二进制记录格式。支持三种格式类型：

*  STATEMENT：基于SQL语句的复制（statement-based replication, SBR）
 *  ROW：基于行的复制（row-based replication, RBR）
 *  MIXED：混合模式复制（mixed-based replication, MBR）

在 MySQL 5.7.7 之前，默认的格式是 STATEMENT，在 MySQL 5.7.7 及更高版本中，默认值是 ROW。日志格式通过 binlog-format 指定，如 binlog-format=STATEMENT、binlog-format=ROW、binlog-format=MIXED。

*  Statement

每一条会修改数据的sql都会记录在binlog中

优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO, 提高了性能。

缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行的时候相同的结果。另外mysql的复制，像一些特定函数的功能，slave与master要保持一致会有很多相关问题。

*  Row

5.1.5版本的MySQL才开始支持 row level 的复制,它不记录sql语句上下文相关信息，仅保存哪条记录被修改。

优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以row的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题.

缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。

注：将二进制日志格式设置为ROW时，有些更改仍然使用基于语句的格式，包括所有DDL语句，例如CREATE TABLE， ALTER TABLE，或 DROP TABLE。

*  Mixed

从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是Statement与Row的结合。  
在Mixed模式下，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。

--------------------

# 1、检查是否开启binlog日志 #

show global variables like "%log_bin%";

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70][]

## 2、配置mysql开启binlog日志 ##

vi /etc/my.cnf

server_id=2
    
    log_bin = mysql-bin
    
    binlog_format = ROW
    
    expire_logs_days = 30

server\_id：随机指定一个不能和其他集群中机器重名的字符串，如果只有一台机器，那就可以随便指定了。

log\_bin：binlog的日志规则名

binlog\_format：Binlog 的日志格式

expire\_logs\_days：设置binlog文件保存事件，过期删除，单位天。

# 3、重启mysql #

# CentOS 6
    service mysqld restart
     
     
    # CentOS 7
    systemctl restart mysqld

# 4、检查是否开启成功 #

show global variables like "%log_bin%";

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 1][]

# 5、binlog日志文件存放路径 #

如上图所示的log\_bin\_basename的/var/lib/mysql

再该路径下会生成

mysql-bin.000001

mysql-bin.000002

这样的文件

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 2][]

# 6、当前MySQL的binlog的情况及查看binlog日志 #

show master status;

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 3][]

从上图可以看到，当前只有一个binlog文件，文件名为：mysql-bin.000001。**每当我们重启一次，会自动生成一个binlog文件**，我们重启完毕之后再来执行同样的命令，内容如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 4][]

存放binlog的目录下也多个了这么一个文件。

当然，我们也可以手动的来刷新binlog文件，通过**flush logs**,同样会新创建一个binlog文件。实际上当服务器在重启时，也会调用flush logs操作。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 5][]

如果我们想把这些文件全部清空，可以使用**reset master** 来处理

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 6][]

下面我来看针对单个文件的操作，首先我们想看一下文件的内容

找到binlog的目录，比如我们要看mysql-bin.000001

vi mysql-bin.000001

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 7][]

我们看到的一堆乱码。我们知道这是一堆的二进制文件，所以以文本的方式打开二进制文件一定是有问题的，那么我们该如何查看这个文件的内容呢？

mysql给我们提供了一个用于查看binlog日志的工具，叫做**mysqlbinlog**

mysqlbinlog mysql-bin.000001

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 8][]

这个文件比较长，一次打开看不完怎么办呢，这里可以使用linux的管道，这里就不详细的说了，可以自己去查找关于linux的一些知识。

注意到下面的截图中有一个position字段，这个字段类似于一个指针，目前这个字段的值为154，表示的就是binlog当前的位置。我们每次执行dml操作，position都会改变。比如我们先来创建一个数据 test

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 9][]

在创建之前我们可以清一下binlog日志方便我们查看，可以使用 reset master。在生产环境中，这个操作是***非常危险***的，那么我们可以使用flush logs来处理，生成一个新的binlog文件。不管采用哪种方式，我们在测试的环境中，只要有一个新的binlog文件就可以了。生成了新的binlog文件之后，我们可以通过show master status 来查看状态。

下面我们来执行一个dml语句，比如我们要创建一个test数据库

create database test;

然后我们来查看创建之后的状态，如下，我们发现position从154变成了418，也就是说我们的操作是在154到418之间，然后我们再来看binlog的内容。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 10][]

[root@PCNCMCNSA0036 mysql]# mysqlbinlog mysql-bin.000001

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 11][]

这里还可以看到 --show --select 等三条被注释的命令是因为我是通过Navicat执行的。

![20210609104442401.png][]

# 7、开启binlog\_rows\_query\_log\_events #

**binlog**是 MySQL Server 层记录的二进制日志文件，用于记录 MySQL 的数据更新或者潜在更新（比如 DELETE 语句执行删除而实际并没有符合条件的数据），**select 或 show**等不会修改数据的操作则不会记录在 binlog 中。通常在 **binlog\_format = ROW**的环境下，我们可以通过 binlog 获取历史的 SQL 执行记录，前提是必须开启 **binlog\_rows\_query\_log\_events**参数（默认关闭，建议开启），该参数可以通过**rows\_query\_event**事件记录原始的 SQL，如果不开启的话，则只能获取 SQL 对应的行数据。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 12][]

vi /etc/my.cnf

binlog_rows_query_log_events=1

# 8、show binlog events #

show binlog events 方式可以解析指定 binlog 日志，但不适宜提取大量日志，速度很慢，不建议使用。

-- 查看最老的binlog
    show binlog events
    
    -- 查看指定的binlog
    show binlog events in 'mysql-bin.000002';
    
    
    -- IN 'log_name' ：指定要查询的binlog文件名(不指定就是第一个binlog文件)
    -- FROM pos ：指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
    -- LIMIT [offset,] ：偏移量(不指定就是0)
    -- row_count ：查询总条数(不指定就是所有行)
    show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

# ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 13][] #

# 9、查看当前服务器使用的biglog文件及大小 #

show binary logs

# ![20210609134949779.png][] #

# 10、设置binlog文件保存事件，过期删除，单位天 #

show global variables like "%expire_logs%";
    
    set global expire_logs_days=3;

# 11、max\_binlog\_size #

# 查询max_binlog_size变量
    show global variables like "%max_binlog_size%";

max\_binlog\_size 的最小值是4096字节，最大值和默认值是 1GB (1073741824字节)。事务被写入到binlog的一个块中，所以它不会在几个二进制日志之间被拆分。因此，如果你有很大的事务，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的日志都记录到当前日志文件中，直到事务结束，你可能会看到binlog文件大于 max\_binlog\_size 的情况。

![20210609135637651.png][]

# 12、binlog日志详解 #

# at 21019
    #190308 10:10:09 server id 1  end_log_pos 21094 CRC32 0x7a405abc 	Query	thread_id=113	exec_time=0	error_code=0
    SET TIMESTAMP=1552011009/*!*/;
    BEGIN
    /*!*/;

上面输出包括信息：

*  position: 位于文件中的位置，即第一行的（\# at 21019）,说明该事件记录从文件第21019个字节开始
 *  timestamp: 事件发生的时间戳，即第二行的（\#190308 10:10:09）
 *  server id: 服务器标识（1）
 *  end\_log\_pos 表示下一个事件开始的位置（即当前事件的结束位置+1）
 *  thread\_id: 执行该事件的线程id （thread\_id=113）
 *  exec\_time: 事件执行的花费时间
 *  error\_code: 错误码，0意味着没有发生错误
 *  type:事件类型Query

# 13、Binlog 事件类型 #

binlog 事件的结构主要有3个版本：

v1: 在 MySQL 3.23 中使用  
v3: 在 MySQL 4.0.2 到 4.1 中使用  
v4: 在 MySQL 5.0 及以上版本中使用  
现在一般不会使用MySQL5.0以下版本，所以下面仅介绍v4版本的binlog事件类型。binlog 的事件类型较多，本文在此做一些简单的汇总

<table> 
 <thead> 
  <tr> 
   <th>事件类型</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>UNKNOWN_EVENT</td> 
   <td>此事件从不会被触发，也不会被写入binlog中；发生在当读取binlog时，不能被识别其他任何事件，那被视为UNKNOWN_EVENT</td> 
  </tr> 
  <tr> 
   <td>START_EVENT_V3</td> 
   <td>每个binlog文件开始的时候写入的事件，此事件被用在MySQL3.23 – 4.1，MYSQL5.0以后已经被 FORMAT_DESCRIPTION_EVENT 取代</td> 
  </tr> 
  <tr> 
   <td>QUERY_EVENT</td> 
   <td>执行更新语句时会生成此事件，包括：create，insert，update，delete；</td> 
  </tr> 
  <tr> 
   <td>STOP_EVENT</td> 
   <td>当mysqld停止时生成此事件</td> 
  </tr> 
  <tr> 
   <td>ROTATE_EVENT</td> 
   <td>当mysqld切换到新的binlog文件生成此事件，切换到新的binlog文件可以通过执行flush logs命令或者binlog文件大于 max_binlog_size 参数配置的大小；</td> 
  </tr> 
  <tr> 
   <td>INTVAR_EVENT</td> 
   <td>当sql语句中使用了AUTO_INCREMENT的字段或者LAST_INSERT_ID()函数；此事件没有被用在binlog_format为ROW模式的情况下</td> 
  </tr> 
  <tr> 
   <td>LOAD_EVENT</td> 
   <td>执行LOAD DATA INFILE 语句时产生此事件，在MySQL 3.23版本中使用</td> 
  </tr> 
  <tr> 
   <td>SLAVE_EVENT</td> 
   <td>未使用</td> 
  </tr> 
  <tr> 
   <td>CREATE_FILE_EVENT</td> 
   <td>执行LOAD DATA INFILE 语句时产生此事件，在MySQL4.0和4.1版本中使用</td> 
  </tr> 
  <tr> 
   <td>APPEND_BLOCK_EVENT</td> 
   <td>执行LOAD DATA INFILE 语句时产生此事件，在MySQL4.0版本中使用</td> 
  </tr> 
  <tr> 
   <td>EXEC_LOAD_EVENT</td> 
   <td>执行LOAD DATA INFILE 语句时产生此事件，在MySQL4.0和4.1版本中使用</td> 
  </tr> 
  <tr> 
   <td>DELETE_FILE_EVENT</td> 
   <td>执行LOAD DATA INFILE 语句时产生此事件，在MySQL4.0版本中使用</td> 
  </tr> 
  <tr> 
   <td>NEW_LOAD_EVENT</td> 
   <td>执行LOAD DATA INFILE 语句时产生此事件，在MySQL4.0和4.1版本中使用</td> 
  </tr> 
  <tr> 
   <td>RAND_EVENT</td> 
   <td>执行包含RAND()函数的语句产生此事件，此事件没有被用在binlog_format为ROW模式的情况下</td> 
  </tr> 
  <tr> 
   <td>USER_VAR_EVENT</td> 
   <td>执行包含了用户变量的语句产生此事件，此事件没有被用在binlog_format为ROW模式的情况下</td> 
  </tr> 
  <tr> 
   <td>FORMAT_DESCRIPTION_EVENT</td> 
   <td>描述事件，被写在每个binlog文件的开始位置，用在MySQL5.0以后的版本中，代替了START_EVENT_V3</td> 
  </tr> 
  <tr> 
   <td>XID_EVENT</td> 
   <td>支持XA的存储引擎才有，本地测试的数据库存储引擎是innodb，所有上面出现了XID_EVENT；innodb事务提交产生了QUERY_EVENT的BEGIN声明，QUERY_EVENT以及COMMIT声明，如果是myIsam存储引擎也会有BEGIN和COMMIT声明，只是COMMIT类型不是XID_EVENT</td> 
  </tr> 
  <tr> 
   <td>BEGIN_LOAD_QUERY_EVENT</td> 
   <td>执行LOAD DATA INFILE 语句时产生此事件，在MySQL5.0版本中使用</td> 
  </tr> 
  <tr> 
   <td>EXECUTE_LOAD_QUERY_EVENT</td> 
   <td>执行LOAD DATA INFILE 语句时产生此事件，在MySQL5.0版本中使用</td> 
  </tr> 
  <tr> 
   <td>TABLE_MAP_EVENT</td> 
   <td>用在binlog_format为ROW模式下，将表的定义映射到一个数字，在行操作事件之前记录（包括：WRITE_ROWS_EVENT，UPDATE_ROWS_EVENT，DELETE_ROWS_EVENT）</td> 
  </tr> 
  <tr> 
   <td>PRE_GA_WRITE_ROWS_EVENT</td> 
   <td>已过期，被 WRITE_ROWS_EVENT 代替</td> 
  </tr> 
  <tr> 
   <td>PRE_GA_UPDATE_ROWS_EVENT</td> 
   <td>已过期，被 UPDATE_ROWS_EVENT 代替</td> 
  </tr> 
  <tr> 
   <td>PRE_GA_DELETE_ROWS_EVENT</td> 
   <td>已过期，被 DELETE_ROWS_EVENT 代替</td> 
  </tr> 
  <tr> 
   <td>WRITE_ROWS_EVENT</td> 
   <td>用在binlog_format为ROW模式下，对应 insert 操作</td> 
  </tr> 
  <tr> 
   <td>UPDATE_ROWS_EVENT</td> 
   <td>用在binlog_format为ROW模式下，对应 update 操作</td> 
  </tr> 
  <tr> 
   <td>DELETE_ROWS_EVENT</td> 
   <td>用在binlog_format为ROW模式下，对应 delete 操作</td> 
  </tr> 
  <tr> 
   <td>INCIDENT_EVENT</td> 
   <td>主服务器发生了不正常的事件，通知从服务器并告知可能会导致数据处于不一致的状态</td> 
  </tr> 
  <tr> 
   <td>HEARTBEAT_LOG_EVENT</td> 
   <td>主服务器告诉从服务器，主服务器还活着，不写入到日志文件中</td> 
  </tr> 
 </tbody> 
</table>

# 14、Binlog 事件的结构 #

如果事件头的长度是 `x` 字节，那么事件体的长度为 `(event_length - x)` 字节；设事件体中 `fixed part` 的长度为 `y` 字节，那么 `variable part` 的长度为 `(event_length - (x + y))` 字节

# 15、总结 #

1.binlog文件会随服务的启动创建一个新文件

2.通过flush logs 可以手动刷新日志，生成一个新的binlog文件

3.通过show master status 可以查看binlog的状态

4.通过reset master 可以清空binlog日志文件

5.通过mysqlbinlog 工具可以查看binlog日志的内容

6.通过执行dml，mysql会自动记录binlog

7.格式化显示binlog日志

mysqlbinlog --no-defaults  --base64-output=decode-rows -v --start-datetime='2019-04-11 00:00:00' --stop-datetime='2021-06-11 15:00:00'  mysql-bin.000001 |more

8、常用格式化binlog命令

-- 个人常用的 Linux 下解析命令：
    
    mysqlbinlog /data/mysql_data/bin.000008 --database EpointFrame --base64-output=decode-rows -vv --skip-gtids=true |grep -C 1 -i "delete from Audit_Orga_Specialtype" > /opt/sql.log

/data/mysql\_data/bin.000008：需要解析的 binlog 日志。

database：只列出该数据库下的行数据，但无法过滤 Rows\_query\_event。

base64-output=decode-rows -vv：显示具体 SQL 语句。

skip-gtids=true：忽略 GTID 显示。

grep -C 1 -i "delete from dataex\_trigger\_record"：通过管道命令筛选出所需 SQL 及执行时间。

/opt/sql.log：将结果导入到日志文件，方便查看。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 14][]

**小贴士：**

1. 如果不确定 SQL 格式或是无法筛选到数据，比如因为 delete from 中间冷不丁多一个空格出来，可以使用 grep 多次过滤筛选，比如 \*\*grep -C 1 -i "Rows\_query" |grep -C 1 -i "Audit\_Orga\_Specialtype" |grep -C 1 -i "delete" \*\*筛选对应表上的 delete 操作。

2. 触发器执行的 SQL 不会记录在 Rows\_query\_event 中，只会记录对应的行数据。

1.  **--database**是无法过滤 Rows\_query\_event 的，只可以过滤行数据。

**三、解析方式对比**

对于常见的数据库（**SQL Server、Oracle、MySQL**）来说，都具有类似相同的日志来记录历史 SQL，不同的只是日志的记录方式和解析方法：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 15][]

# 16、mysql查看正在执行的sql语句和查看已经执行的历史sql语句 #

一、mysql查看正在执行的sql语句

show processlist;

二、mysql查看已经执行的历史sql语句（方法：开启日志模式）

SET GLOBAL log_output = 'TABLE';SET GLOBAL general_log = 'ON';  //日志开启

你输入要查的语句，比如 select \* from iot.tb\_iot ;

在查询sql语句之后，在对应的 /var/lib/mysql/mysql/general\_log.CSV 里有对应的log记录

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 16][]

SET GLOBAL log\_output = 'TABLE'; SET GLOBAL general\_log = 'OFF'; //日志关闭

注意：在查询到所需要的记录之后，应尽快关闭日志模式，占用磁盘空间比较大

[20210609141904650.png]: /images/20221005/50fc725aa2ff443fbac86ddf9a631abc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70]: /images/20221005/a4aaca9d26e546c0993c4a141ac3ee04.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 1]: /images/20221005/ba6cafebd9f04590a870fe7cbe4aa959.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 2]: /images/20221005/e0899b830aa342d582bc805696914aeb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 3]: /images/20221005/b47b2b46fb664d3186672995dba85e54.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 4]: /images/20221005/37d85713a4974c18b5c39dbeb3017692.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 5]: /images/20221005/549b14cac89d4ffda15c1b54b6ec7301.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 6]: /images/20221005/9241858687fc44b78f0ae1aa48e522f1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 7]: /images/20221005/dbd798532acc4ea6adb7e14a70b515a2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 8]: /images/20221005/b5710769063544138cd7777cdfb2b386.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 9]: /images/20221005/274bea99bbd745ba872c87c6a1120675.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 10]: /images/20221005/3ff385f69d3840dd8b104e7bd56fc8f8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 11]: /images/20221005/bd94bcf8442d4290963037a27eece6e5.png
[20210609104442401.png]: /images/20221005/bf248ea91acf4bb3b7620360bc734c39.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 12]: /images/20221005/51f1c3938ce448598cb310db76fac4b3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 13]: /images/20221005/5e52106006f1473aaff81c03854ba711.png
[20210609134949779.png]: /images/20221005/a4ba4261511f4cf198da8c1c2e80d02a.png
[20210609135637651.png]: /images/20221005/a65511078eab47baaa0b4fdcb79cc24f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 14]: /images/20221005/10ec8abd4c224287be37166b7d7eb144.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 15]: /images/20221005/58ac84fc2d80441a9d99e067b4e74fde.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pFTlJFWQ_size_16_color_FFFFFF_t_70 16]: /images/20221005/58c15f14989046d9a0c4f0dd698a5b76.png