MySQL 日志

目录

slow query log(慢查询日志)

binlog(二进制日志)

binlog 的格式有哪几种?

binlog 的刷盘时机

什么情况下会重新生成 binlog?


MySQL 中常见的日志类型主要有下面几类(针对的是 InnoDB 存储引擎):

  • 错误日志(error log) :对 MySQL 的启动、运行、关闭过程进行了记录。
  • 二进制日志(binary log,binlog) :主要记录的是更改数据库数据的 SQL 语句。
  • 一般查询日志(general query log) :已建立连接的客户端发送给 MySQL 服务器的所有 SQL 记录,因为 SQL 的量比较大,默认是不开启的,也不建议开启。
  • 慢查询日志(slow query log) :执行时间超过 long_query_time秒钟的查询,解决 SQL 慢查询问题的时候会用到。
  • 事务日志(redo log 和 undo log) :redo log 是重做日志,undo log 是回滚日志。
  • 中继日志(relay log) :relay log 是复制过程中产生的日志,很多方面都跟 binary log 差不多。不过,relay log 针对的是主从复制中的从库。
  • DDL 日志(metadata log) :DDL 语句执行的元数据操作。

 

slow query log(慢查询日志)

慢查询日志记录了执行时间超过 long_query_time(默认是 10s,通常设置为1s)的所有查询语句,方便我们解决 SQL 慢查询(SQL 执行时间过长)问题。

找到慢 SQL 是优化 SQL 语句性能的第一步,然后再用EXPLAIN 命令可以对慢 SQL 进行分析,获取执行计划的相关信息。

可以通过 show variables like "slow_query_log";命令来查看慢查询日志是否开启,默认是关闭的。

mysql> show variables like 'slow_query_log';
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| slow_query_log | OFF   |
+----------------+-------+

 可以通过

SET GLOBAL slow_query_log=ON

命令将其开启。

long_query_time 参数定义了一个查询消耗多长时间才可以被定义为慢查询,默认是 10s,通过

SHOW VARIABLES LIKE '%long_query_time%'

命令即可查看。

并且,我们还可以对 long_query_time 参数进行修改:

SET GLOBAL long_query_time=1

binlog(二进制日志)

binlog(binary log 即二进制日志文件) 主要记录了对 MySQL 数据库执行了更改的所有操作(数据库执行的所有 DDL 和 DML 语句),包括表结构变更(CREATE、ALTER、DROP TABLE…)、表数据修改(INSERT、UPDATE、DELETE...),但不包括 SELECT、SHOW 这类不会对数据库造成更改的操作。

不过,并不是不对数据库造成修改就不会被记录进 binlog。即使表结构变更和表数据修改操作并未对数据库造成更改,依然会被记录进 binlog。

binlog 的格式有哪几种?

一共有 3 种类型二进制记录方式:

  • Statement 模式 :每一条会修改数据的sql都会被记录在binlog中,如inserts, updates, deletes。
  • Row 模式 (推荐): 每一行的具体变更事件都会被记录在binlog中。
  • Mixed 模式 :Statement 模式和 Row 模式的混合。默认使用 Statement 模式,少数特殊具体场景自动切换到 Row 模式。

MySQL 5.1.5 之前 binlog 的格式只有 STATEMENT,5.1.5 开始支持 ROW 格式的 binlog,从 5.1.8 版本开始,MySQL 开始支持 MIXED 格式的 binlog。MySQL 5.7.7 之前,默认使用 Statement 模式。MySQL 5.7.7 开始默认使用 Row 模式。

相比较于 Row 模式来说,Statement 模式下的日志文件更小,磁盘 IO 压力也较小,性能更好有些。不过,其准确性相比于 Row 模式要差。

可以使用 

show variables like '%binlog_format%'

查看 binlog 使用的格式。

binlog 的刷盘时机

对于InnoDB存储引擎而言,事务在执行过程中,会先把日志写入到binlog cache中,只有在事务提交的时候,才会把binlog cache中的日志持久化到磁盘上的binlog文件中。写入内存的速度更快,这样做也是为了效率考虑。

因为一个事务的binlog不能被拆开,无论这个事务多大,也要确保一次性写入,所以系统会给每个线程分配一个块内存作为binlog cache。我们可以通过binlog_cache_size参数控制单个线程 binlog cache 大小,如果存储内容超过了这个参数,就要暂存到磁盘(Swap)。

那么 binlog 是什么时候刷到磁盘中的呢? 可以通过  sync_binlog 参数控制 biglog 的刷盘时机,取值范围是 0-N,默认为 0 :

  • 0:不去强制要求,由系统自行判断何时写入磁盘;
  • 1:每次提交事务的时候都要将binlog写入磁盘;
  • N:每 N 个事务,才会将binlog写入磁盘。

MySQL5.7 之前, sync_binlog 默认值为 0。在 MySQL5.7 之后, sync_binlog默认值为 1。

什么情况下会重新生成 binlog?


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

  • MySQL服务器停止或重启;
  • 使用 flush logs 命令后;
  • binlog 文件大小超过 max_binlog_size变量的阈值后。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值