MySQL 重要日志文件汇总示例

这篇文章主要为大家详细介绍了MySQL 重要日志文件汇总示例，具有一定的参考价值，可以用来参考一下。

感兴趣的小伙伴，下面一起跟随数据库教程的小编来看看吧！

日志是所有应用的重要数据，MySQL 也有错误日志、查询日志、慢查询日志、事务日志等。本文简单总结下各种日志，以备查阅。

二进制日志 binlog

二进制日志 binlog 用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。使用任何存储引擎的 mysql 数据库都会记录 binlog 日志。在 binlog 中记录的是逻辑日志，也就是 SQL 语句。SQL 语句执行后，binlog 追加到日志文件中。可以设置 binlog 文件大小，超过大小后，自动创建新的文件。

binlog 有三种格式，分别为 STATMENT、ROW 和 MIXED。

• STATMENT：把会修改数据的 sql 语句记录到 binlog 中；是 MySQL 5.7.7 之前的默认格式；
• ROW：不记录每条 sql 语句的上下文信息，仅记录哪条数据被修改了；是 MySQL 5.7.7之后的默认格式；
• MIXED：基于 STATMENT 和 ROW 两种模式的混合复制，一般使用 STATEMENT 模式，对于无法复制的操作使用 ROW 模式；

在实际应用中，binlog 主要用于主从复制和数据恢复。主从复制是指在 master 机器开启 binlog，通过某种方式把 binlog 发送给 slave 机器，slave 机器根据 binlog 内容进行数据操作，从而保证主从数据一致性。另外，通过使用 mysqlbinlog 工具可以从 binlog 恢复数据。

在 MySQL 5.7 之后，内置默认引擎已经变更为 InnoDB 引擎。 InnoDB 引擎在处理事务时，可以设置日志写入磁盘的时机，默认情况下是每次 commit 时写入磁盘。也可以通过 sync_binlog 参数设置成系统自动判断或每 N 个事务写入一次。

查询日志

查询日志记录了所有数据库请求的信息。无论这些请求是否得到了正确的执行。开启之后对性能有比较大的影响，因此使用不多。

慢查询日志

慢查询日志用来记录执行时间超过某个阈值的语句。执行时间阈值可以通过 long_query_time 来设置，默认是 10 秒。慢查询日志需要手动开启，对性能有一些影响，一般不建议开启。慢查询日志支持将记录写入文件，也支持写入数据库表。

事务日志 redo log

事务的四大特性之一是持久性。因此事务成功后，数据库的修改永久保存，不能因为任何原因而回到原来的状态。redo log 是 InnoDB 引擎层实现的日志，并不是所有引擎都有，用来记录事务对数据页的修改，可以在崩溃时用于恢复数据。redo log 包括内存中的日志缓冲和磁盘上的日志文件。执行 SQL 语句后，先写入日志缓冲，后续再一次性把多条缓冲写入文件。

在 InnoDB 中，数据页也会刷盘，redo log 存在的意义主要就是降低对数据页刷盘的要求。数据页的变更，redo log 没有必要全部保存。如果数据页刷盘比 redo log 快，则 redo log 的记录对于数据恢复意义不大；如果数据页刷盘比 redo log 慢，则 redo log 中比数据页快的部分可以用来快速恢复数据。因此 redo log 日志文件大小是固定的，当写到结尾时，会回到开头循环写日志。

事务日志 undo log

事务的四大特性之一是原子性。对数据库的一系列操作，要么全部成功，要么全部失败，不允许部分成功部分失败。因此，需要记录数据的逻辑变化。原子性通过 undo log 来实现，比如事务中执行一条 insert 语句，undo log 就会记录一条 delete 语句；事务中执行一条 update 语句，undo log 就会记录一条相反的 update 语句。这样在事务失败时，就可以通过 undo log 来回滚到事务之前的状态。

以上就是mysql 重要日志文件汇总的详细内容，更多关于MySQL 日志文件的资料请关注512笔记其它相关文章！

注：关于MySQL 重要日志文件汇总示例的内容就先介绍到这里，更多相关文章的可以留意