mysql日志详解

2024年7月11日 1,048次阅读 0人点赞

mysql日志的种类

日志种类 描述 作用
redo 重做日志 确保日志的持久性 防止在发生故障时，脏页未写入磁盘。重启数据库会进行redo log执行重做，达到事务一致性
undo 回滚日志 保证数据的原子性 记录事务发生之前的一个版本，用于回滚。InnoDB事务的可重复读和读取已提交隔离级别通过MVCC+undo实现
errlog 错误日志 记录MySQL本身错误信息 记录MySQL启动、停止、运行期间发生的错误信息
slow query log 慢查询日志 记录执行时间过长的SQL 记录执行时间超过配置阈值的SQL语句，只记录执行成功的语句
bin log 二进制日志 用于主从复制 记录数据库更改的所有信息，用于主从复制和数据恢复
relay log 中继日志 用于数据库主从同步 在从库中，将主库发来的bin log保存在本地，然后从库进行回放以实现主从同步
general log 普通日志 记录数据库的操作明细 记录数据库服务器的所有操作，包括客户端连接和断开、SQL语句执行等。默认关闭，开启后会降低数据库性能

bin log日志

查看二进制日志（Binary Log）是否开启

MariaDB [(none)]> SHOW VARIABLES LIKE 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.00 sec)

MariaDB [(none)]> SHOW binary logs;
+---------------+-----------+
| Log_name      | File_size |
+---------------+-----------+
| master.000001 |       684 |
| master.000002 |       245 |
| master.000003 |       264 |
| master.000004 |       264 |
| master.000005 |       264 |
| master.000006 |       732 |
| master.000007 |       264 |
| master.000008 |       245 |
+---------------+-----------+

配置主从同步

查看日志状态

MariaDB [(none)]> show master status;
+---------------+----------+--------------+------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| master.000008 |      245 |              |                  |
+---------------+----------+--------------+------------------+
1 row in set (0.00 sec)

 change master to 
 master_host="192.168.126.21",
 master_user="repluser",
 master_password="123456",
 master_log_file="master.000008",
 master_log_pos=245;

 start slave;

 MariaDB [(none)]> show slave status \G;

常用命令

查看日志文件内容

mysqlbinlog  master.000001

实际工作中，二进制日志文件与数据库的数据文件不放在同一块硬盘上，这样即使数据文件所在的硬盘被破坏，也可以使用另一块硬盘上的二进制日志来恢复数据库文件，保证数据库中数据的安全。

删除所有的二进制文件

RESET MASTER

删除指定编号之前的日志

PURGE MASTER LOGS TO master.000006

删除指定时间之前创建的二进制日志

PURGE MASTER LOGS TO ‘yyyy-mm-dd hh:MM:ss’;

下面命令中，0 表示暂停二进制日志功能，1 表示开启二进制功能。

SET SQL_LOG_BIN=0/1;

使用binlog还原数据库操作，需要按顺序从小到大还原

mysqlbinlog master.000001 | mysql -u root -p
mysqlbinlog master.000002 | mysql -u root -p

当涉及到my.cnf中关于二进制日志（binlog）的配置时，以下是一个简单的表格，列出了常见的配置参数及其描述：

bin log参数

配置参数 描述 示例值
log_bin 是否启用二进制日志，以及日志文件的路径和前缀 log_bin=/var/log/mysql/mysql-bin
binlog_format 二进制日志的格式（STATEMENT, ROW, MIXED） binlog_format=ROW
expire_logs_days binlog文件在被自动删除前保留的天数 expire_logs_days=7
binlog_cache_size 二进制日志缓存大小 binlog_cache_size=32M
max_binlog_cache_size 最大的二进制日志缓存大小 max_binlog_cache_size=512M
max_binlog_size 单个二进制日志文件的最大大小 max_binlog_size=100M
binlog_do_db 指定需要记录binlog的数据库，多个数据库用逗号分隔 binlog_do_db=db1,db2
binlog_ignore_db 指定不需要记录binlog的数据库，多个数据库用逗号分隔 binlog_ignore_db=mysql,information_schema
sync_binlog 控制二进制日志同步到磁盘的频率（每多少次事务提交后同步一次） sync_binlog=1
binlog_checksum 控制是否在binlog中启用校验和（从MySQL 5.6.3开始） binlog_checksum=CRC32

请注意，binlog_do_db和binlog_ignore_db这两个参数可以用来控制哪些数据库的更改会被记录到binlog中，但通常不建议使用它们，因为管理起来可能会很复杂。更好的做法是在应用程序层面控制哪些操作需要记录到binlog中。

另外，sync_binlog参数的值设置为1表示每次事务提交时都会将binlog同步到磁盘，这可以提供更高的数据安全性，但可能会降低性能。你可以根据具体的硬件环境和业务需求来设置这个值。

最后，binlog_checksum参数用于启用或禁用binlog中的校验和。启用它可以增加binlog的完整性，但可能会稍微降低性能。从MySQL 5.6.3开始，CRC32是默认的校验和算法。

binlog_format

格式 STATEMENT (SBR) ROW (RBR) MIXED (MBR)
描述 记录导致数据更改的SQL语句 记录数据行的实际更改 基于语句和基于行的混合
优点 1. 历史悠久，技术成熟 1. 复制安全可靠 1. 智能选择，提供最佳性能和可靠性
2. binlog文件较小 2. 从库执行效率高 2. 提供了STATEMENT和ROW格式的优点
3. 可用于审核数据库更改 3. 锁开销小（特定场景）
4. 可用于实时恢复
缺点 1. 复制可靠性问题 1. binlog文件较大 1. 配置相对复杂
2. 主从数据不一致风险 2. 复杂回滚开销大
3. 复杂语句的复制性能问题 3. 主库更新开销大（特定场景）
适用场景 1. 对binlog大小敏感 1. 需要高可靠性和数据一致性 1. 默认格式，适用于大多数场景
2. 需要审计和追踪数据更改 2. 复杂更新操作 2. 自动权衡性能和可靠性
示例值 binlog_format=STATEMENT binlog_format=ROW binlog_format=MIXED（MySQL 5.7.7+默认）

请注意，在选择 binlog_format 时，您应该考虑您的具体需求和环境。例如，如果您需要高可靠性和数据一致性，那么 ROW 格式可能是更好的选择。而如果您对 binlog 的大小敏感，或者需要审计和追踪数据更改，那么 STATEMENT 格式可能更适合您。MIXED 格式则提供了一个自动权衡性能和可靠性的解决方案。

中继日志

中继日志的作用

中继日志用于主从服务器架构中，从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过读取中继日志的内容，来同步主服务器上的操作。

中继日志是连接master(主服务器)和slave(从服务器)的信息，它是复制的核心，I/O线程将来自master的binlog存储到中继日志中，中继日志充当缓冲，这样master不必等待slave执行完成就可以发送下一个binlog。

查看中继日志

中继日志文件的格式与二进制日志文件相同，并且可以使用mysqlbinlog进行读取。

相关参数解析

通过语句：show variables like ‘%relay%’查看relay所有相关参数如下

MariaDB [(none)]> show variables like '%relay%';
+----------------------------------+----------------+
| Variable_name                    | Value          |
+----------------------------------+----------------+
| innodb_recovery_update_relay_log | OFF            |
| max_relay_log_size               | 0              |
| relay_log                        |                |
| relay_log_index                  |                |
| relay_log_info_file              | relay-log.info |
| relay_log_purge                  | ON             |
| relay_log_recovery               | OFF            |
| relay_log_space_limit            | 0              |
| sync_relay_log                   | 0              |
| sync_relay_log_info              | 0              |
+----------------------------------+----------------+

下面是对每个参数的简单解释：

  1. innodb_recovery_update_relay_log
    • 这个参数主要用于InnoDB的恢复模式，但通常不用于常规的复制设置。它决定了在恢复过程中是否更新中继日志。
    • OFF 表示在恢复过程中不更新中继日志。
  2. max_relay_log_size
    • 这个参数用来定义单个中继日志文件可以达到的最大大小（以字节为单位）。
    • 0 表示没有限制，但通常不建议设置为0，因为这可能导致非常大的日志文件。
  3. relay_log
    • 这个参数指定了中继日志文件的基本名称。
    • 如果为空（“），则MySQL会使用主机名来生成文件名。
  4. relay_log_index
    • 这个参数指定了包含所有中继日志文件名的索引文件的名称。
    • 如果为空（“），则MySQL会使用与relay_log相同的名称，但添加.index后缀。
  5. relay_log_info_file
    • 这个参数指定了包含中继日志状态信息的文件的名称。
    • relay-log.info 是默认值，它记录了从服务器读取中继日志的位置，以便在服务器重启后知道从哪里开始复制。
  6. relay_log_purge
    • 这个参数决定了是否自动删除不再需要的中继日志文件。
    • ON 表示自动删除。当不再需要这些日志文件时（即，当从服务器已经读取了所有包含在这些文件中的事件时），它们将被删除。
  7. relay_log_recovery
    • 这个参数主要用于在从服务器崩溃后恢复时。
    • OFF 表示不尝试从中继日志中恢复。
  8. relay_log_space_limit
    • 这个参数限制了从服务器可以使用的中继日志空间的最大量（以字节为单位）。
    • 0 表示没有限制。
  9. sync_relay_log
    • 这个参数决定了多少次事务提交后，MySQL会将中继日志的内容刷新到磁盘。
    • 0 表示不立即刷新，而是依赖于操作系统的调度。设置为非零值可以增加数据的安全性，但可能会降低性能。
  10. sync_relay_log_info
    • 这个参数决定了多久将relay-log.info文件的内容刷新到磁盘。
    • 0 表示不立即刷新。设置为非零值可以增加数据的安全性，但可能会降低性能。

Redo Log

事务有4种特性：原子性、一致性、隔离性和持久性（ACID）。那么事务的四种特性到底是基于什么机制实现呢？

  • 事务的隔离性由锁机制实现。
  • 而事务的原子性、一致性和持久性由事务的 Redo 日志和 Undo 日志来保证。

Redo Log称为重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。

UNDO LOG称为回滚日志，回滚行记录到某个特定版本，用来保证事务的原子性、一致性。

Redo Log:是存储引擎层(InnoDB)生成的日志，记录的是”物理级别”上的页修改操作，比如页号xx、偏移量yyy写入了’zzz’数据。主要为了保证数据的可靠性

Undo Log:是存储引擎层(Innodb)生成的日志，记录的是逻辑操作日志，比如对某一行数据进行了INSERT语句操作，那么Undo Log 就记录一条与之相反的DELETE操作。主要用于事务的回滚(Undo Log 记录的是每个修改操作的逆操作)和一致性非锁定读(Undo Log回滚行记录到某种特定的版本—MVCC，即多版本并发控制)。

Redo Log跟Binlog的区别，Redo Log是存储引擎层产生的，而Binlog是数据库层产生的。假设一个事务，对表做10万行的记录插入，在这个过程中，一直不断的往Redo Log顺序记录，而 Binlog 不会记录，直到这个事务提交，才会一次写入到 Binlog 文件中。

Redo Log可以简单分为以下两个部分：

  • 重做日志的缓冲 (Redo Log Buffer)：保存在内存中，是易失的。
  • 重做日志文件(Redo Log File)：保存在硬盘中，是持久的。

Redo Log流程

  • 第1步：先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝
  • 第2步：生成一条重做日志并写入Redo Log Buffer，记录的是数据被修改后的值
  • 第3步：当事务commit时，将Redo Log Buffer中的内容刷新到 Redo Log File，对 Redo Log File采用追加写的方式
  • 第4步：定期将内存中修改的数据刷新到磁盘中

Redo Log的刷盘策略

Redo Log的写入并不是直接写入磁盘的，InnoDB引擎会在写Redo Log的时候先写Redo Log Buffer，之后以一定的频率刷入到真正的Redo Log File中。

有几种场景可能会触发redo log写文件：

  • Redo log buffer空间不足时
  • 事务提交
  • 后台线程
  • 做checkpoint
  • 实例shutdown时
  • binlog切换时

注意，Redo Log Buffer刷盘到Redo Log File的过程并不是真正的刷到磁盘中去，只是刷入到文件系统缓存（page cache）中去（这是现代操作系统为了提高文件写入效率做的一个优化），真正的写入会交给系统自己来决定（比如 page cache 足够大了）。那么对于InnoDB来说就存在一个问题，如果交给系统来同步，同样如果系统宕机，那么数据也丢失了（虽然整个系统宕机的概率还是比较小的）。mysql提供以下参数解决。

innodb_flush_log_at_trx_commit 参数，该参数控制 commit 提交事务时，如何将 Redo Log Buffer 中的日志刷新到 Redo Log File 中。

redo log相关的参数及其解释：

  1. innodb_log_file_size
    • 描述：指定每个redo log文件的大小。
    • 默认值：取决于MySQL版本和安装时的配置。
    • 示例值：innodb_log_file_size = 128M（表示每个redo log文件大小为128MB）
    • 注意事项：
      • 修改此参数可能需要重新创建redo log文件，这通常涉及停止MySQL服务、移动或删除旧的redo log文件，然后重启MySQL服务。
      • 较大的redo log文件可以提高写入性能，但也会增加恢复时间。
  2. innodb_log_files_in_group
    • 描述：指定redo log组中的日志文件数量。
    • 默认值：通常为2。
    • 示例值：innodb_log_files_in_group = 2（表示redo log组中有两个日志文件）
    • 注意事项：
      • 在MySQL运行过程中，这两个文件会轮流进行写入，以实现循环使用。
      • 如果设置的值大于2，则会有更多的redo log文件参与循环，但也会增加管理和恢复的复杂性。
  3. innodb_log_group_home_dir
    • 描述：指定redo log文件存储的目录。
    • 默认值：通常是MySQL的数据目录。
    • 示例值：innodb_log_group_home_dir = /var/lib/mysql/（表示redo log文件存储在/var/lib/mysql/目录下）
    • 注意事项：
      • 确保该目录具有足够的磁盘空间和权限，以便MySQL服务能够正常写入redo log文件。
  4. innodb_flush_log_at_trx_commit
    • 描述：控制事务提交时redo log的刷新行为。
    • 可选值：
      • 0：每秒将redo log刷新到磁盘一次，并且只刷新到操作系统的缓存中，而不是直接写入磁盘。
      • 1（默认值）：每次事务提交时都将redo log直接写入磁盘。
      • 2：每次事务提交时都将redo log写入操作系统的缓存，但每秒只刷新到磁盘一次。
    • 示例值：innodb_flush_log_at_trx_commit = 1
    • 注意事项：
      • 值为1提供了最高的数据持久性和完整性保证，但也可能影响性能。
      • 值为0或2可以提高性能，但可能会增加数据丢失的风险。
  5. innodb_flush_method
    • 描述：控制如何将数据和redo log刷新到磁盘。
    • 可选值：
      • fdatasync（默认值）：只刷新文件的数据部分。
      • O_DSYNC：只刷新文件的元数据和数据部分。
      • O_DIRECT：直接写入磁盘，绕过操作系统的缓存。
    • 示例值：innodb_flush_method = fdatasync
    • 注意事项：
      • 不同的值可能会对性能和数据持久性产生不同的影响。
      • 在某些操作系统和硬件上，某些值可能不被支持或表现不佳。

Error Log错误日志

错误日志（Error Log） 是MySQL中最常用的一种日志，主要记录MySQL服务器启动和停止过程中的信息、服务器在运行过程中发生的故障和异常情况等。

错误日志相关参数：

  1. log_error
  • 描述：此参数用于指定错误日志文件的路径和名称。
  • 默认值：在大多数MySQL安装中，默认位置通常是MySQL数据目录下的主机名.err文件，例如/var/lib/mysql/hostname.err。
  • 示例值：log_error = /var/log/mysql/error.log
  • 注意事项：确保指定的目录存在且MySQL服务有权限写入。
  1. log_error_verbosity
  • 描述：此参数用于控制错误日志的详细程度。
  • 可选值：
    • 1：只记录错误消息（默认值）。
    • 2：记录错误和警告消息。
    • 3：记录错误、警告和通知消息。
  • 示例值：log_error_verbosity = 2
  • 注意事项：在高详细程度下，日志文件可能会增长得更快，因此需要考虑磁盘空间的使用情况。
  1. log_warnings

    （注意：在MySQL 8.0.3之后被移除）

  • 描述：在MySQL 8.0.3之前的版本中，此参数用于控制是否将警告信息也写入错误日志。
  • 可选值：
    • 0：不记录警告信息。
    • 1：记录警告信息。
    • 大于1：记录更详细的警告信息。
  • 注意事项：由于此参数在MySQL 8.0.3之后被移除，因此在新版本中无需考虑此参数。
  1. 查看错误日志位置

  • 可以通过执行以下SQL命令来查看当前MySQL错误日志文件的路径和名称：

    sql
    SHOW VARIABLES LIKE 'log_error';

  • 执行结果将返回一个名为log_error的变量，其值即为错误日志文件的路径和名称。

  1. 管理错误日志
  • 如果需要手动管理错误日志（例如，重命名、移动或删除旧的日志文件），请确保在MySQL服务停止时进行，以避免数据丢失或损坏。
  • 在某些情况下，可以通过执行mysqladmin flush-logs命令来轮转错误日志文件，这将会创建一个新的日志文件并关闭当前的日志文件。

General Query Log

通用查询日志（General Query Log） 用来记录用户的所有操作，包括启动和关闭MySQL服务、所有用户的连接开始时间和截止时间、发给MySQL数据库服务器的所有SQL指令等。

MariaDB [(none)]> SHOW VARIABLES LIKE '%general%';
+------------------+------------+
| Variable_name    | Value      |
+------------------+------------+
| general_log      | OFF        |
| general_log_file | nnode1.log |
+------------------+------------+
2 rows in set (0.00 sec)

General Query Log相关参数

  1. general_log
    • 描述：此参数用于控制是否启用通用查询日志功能。
    • 可选值：
      • ON：启用通用查询日志。
      • OFF：禁用通用查询日志（默认值）。
    • 示例：在MySQL的配置文件（如my.cnf或my.ini）中设置[mysqld] general_log=ON来启用通用查询日志。
  2. general_log_file
    • 描述：此参数用于指定通用查询日志文件的路径和名称。
    • 默认值：如果不指定，通用查询日志将默认存储在MySQL数据目录中的hostname.log文件中，其中hostname表示主机名。
    • 示例：在MySQL的配置文件中设置[mysqld] general_log_file=/var/log/mysql/general.log来指定通用查询日志文件的路径和名称。
  3. log_output
    • 描述：此参数用于控制通用查询日志的输出格式和位置。
    • 可选值：
      • TABLE：将日志记录到MySQL系统表（不推荐，因为可能会影响性能）。
      • FILE：将日志记录到文件（默认值）。
      • TABLE,FILE：同时记录到文件和表。
    • 示例：在MySQL的配置文件中设置[mysqld] log_output=FILE来指定将通用查询日志记录到文件。
  4. 动态控制
    • 除了在配置文件中设置上述参数外，还可以使用SQL命令动态地开启或关闭通用查询日志，以及更改日志文件的位置。
    • 开启通用查询日志：SET GLOBAL general_log = 'ON';
    • 关闭通用查询日志：SET GLOBAL general_log = 'OFF';
    • 更改日志文件位置：SET GLOBAL general_log_file = '/path/to/your/logfile.log';

mysqladmin flush-logs

mysqladmin -uroot -p flush-logs 命令用于在MySQL服务器上刷新并重新打开日志文件，这通常包括错误日志、慢查询日志、二进制日志（如果已启用）和查询日志（如果已启用）。

具体来说，flush-logs 命令会执行以下操作：

  1. 关闭并重新打开错误日志文件：如果配置了log_error参数，MySQL会关闭当前的错误日志文件，并开始写入一个新的日志文件。这有助于避免日志文件变得过大，或者为了其他管理目的（如备份或归档）。
  2. 关闭并重新打开慢查询日志文件：如果启用了慢查询日志（通过slow_query_log参数），MySQL会执行与错误日志相同的操作，关闭当前的慢查询日志文件并开始写入一个新的日志文件。
  3. 滚动二进制日志文件：如果启用了二进制日志（通过log_bin参数），flush-logs 会导致MySQL关闭当前的二进制日志文件并开始写入一个新的文件。这在复制环境中特别有用，因为它允许管理员定期滚动二进制日志文件，从而避免它们变得过大。
  4. 关闭并重新打开查询日志文件：如果启用了查询日志（通过general_log参数），该命令也会执行与错误日志和慢查询日志相同的操作。

注意：

  • 使用 mysqladmin 命令时，-u 参数后面跟的是MySQL用户名（在这个例子中是root），-p 参数表示提示输入该用户的密码。
  • 执行此命令可能需要相应的权限。
  • 在执行此命令之前，请确保了解该命令的影响，特别是如果你依赖于日志文件进行故障排除或审计。
  • 在生产环境中，你可能希望定期执行此命令（例如，通过cron作业）以管理日志文件的大小和数量。

最后，如果你只想刷新某个特定的日志文件（例如，只刷新慢查询日志），你可能需要查找其他方法或工具来实现这一目的，因为 mysqladmin flush-logs 命令会刷新所有可刷新的日志文件。

慢查询日志

慢查询日志（Slow Query Log）在MySQL中起着至关重要的作用，主要用于记录执行时间超过指定阈值的SQL语句。以下是慢查询日志的主要作用：

  1. 性能调优：
    通过分析慢查询日志，可以找出那些执行效率低下的SQL语句。这些语句可能是因为缺少索引、查询设计不合理、数据量大等原因导致的。找到这些语句后，可以针对性地进行优化，比如添加合适的索引、优化查询逻辑、调整数据库结构等，从而提升数据库的整体性能。
  2. 问题诊断：
    当数据库出现性能瓶颈或故障时，慢查询日志是诊断问题的重要工具。通过查看慢查询日志，可以定位到导致性能问题的SQL语句，进而分析问题的原因。比如，如果某个SQL语句的执行时间突然变长，可能是由于数据表中的数据量增加、索引失效、硬件资源不足等原因导致的。
  3. 监控和报警：
    结合监控工具和慢查询日志，可以设置报警阈值，当慢查询数量超过一定阈值时触发报警。这有助于及时发现潜在的性能问题，避免问题扩大化。
  4. 优化索引：
    通过分析慢查询日志中的SQL语句，可以发现哪些查询没有利用到索引，或者利用到的索引不够高效。这有助于优化数据库中的索引，提高查询效率。
  5. SQL语句审计：
    慢查询日志还可以用于SQL语句的审计。通过查看慢查询日志，可以了解哪些SQL语句被频繁执行，以及它们的执行时间和资源消耗情况。这有助于发现潜在的SQL注入攻击、数据泄露等安全问题。
  6. 评估硬件升级效果：
    在进行硬件升级（如增加内存、更换磁盘等）后，可以通过分析慢查询日志来评估升级效果。如果升级后慢查询数量显著减少，说明硬件升级取得了明显的效果。

慢查询日志相关的参数：

  1. slow_query_log
  • 描述：该参数控制是否启用慢查询日志。
  • 可选值：
    • 0：禁用慢查询日志（默认值）。
    • 1：启用慢查询日志。
  • 示例：slow_query_log = 1
  1. slow_query_log_file
  • 描述：指定慢查询日志文件的路径和名称。如果不设置该参数，系统会默认使用一个基于主机名的文件名，如hostname-slow.log。
  • 示例：slow_query_log_file = /var/log/mysql/mysql-slow.log
  1. long_query_time
  • 描述：慢查询的时间阈值，单位是秒。任何查询执行时间超过这个值的SQL语句，都会被记录到慢查询日志中。
  • 默认值：10秒
  • 示例：long_query_time = 2（将阈值设置为2秒）
  • 注意：查询执行时间大于long_query_time的SQL语句才会被记录，等于long_query_time的SQL语句不会被记录。
  1. log_queries_not_using_indexes
  • 描述：该参数控制是否记录那些没有使用索引的查询。
  • 可选值：
    • 0：不记录（默认值）。
    • 1：记录。
  • 示例：log_queries_not_using_indexes = 1
  1. log_output
  • 描述：该参数控制慢查询日志的输出方式。
  • 可选值：
    • ‘FILE’：将日志写入文件（默认值）。
    • ‘TABLE’：将日志写入到MySQL数据库的mysql.slow_log表中。
    • ‘FILE,TABLE’：同时写入文件和数据库表。
  • 示例：log_output = 'FILE,TABLE'
  1. log_throttle_queries_not_using_indexes
  • 描述：当log_queries_not_using_indexes启用时，该参数限制每分钟记录到慢查询日志中未使用索引的查询数量。
  • 默认值：0（不限制）
  • 示例：log_throttle_queries_not_using_indexes = 100（每分钟最多记录100条未使用索引的查询）
  1. log_slow_admin_statements
  • 描述：控制是否将管理类的SQL语句（如ALTER TABLE, ANALYZE TABLE等）记录到慢查询日志中。
  • 可选值：
    • 0：不记录（默认值）。
    • 1：记录。
  1. log_slow_slave_statements
  • 描述：控制MySQL从库是否记录慢查询日志。
  • 可选值：
    • 0：不记录（默认值）。
    • 1：记录。

参考

MySQL日志 – Relay Log中继日志的介绍 (qq.com)

MySQL日志 – Redo Log重做日志 (qq.com)

作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可
点赞
标签：

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注