| 失效链接处理 |
|
MySQL 日志：常见的日志都有什么用？ PDF 下载
本站整理下载：
相关截图：
主要内容：
MySQL 中常⻅的⽇志类型主要有下⾯⼏
类（针对的是 InnoDB 存储引擎）：
错误⽇志（error log） ：对 MySQL
的启动、运⾏、关闭过程进⾏了记
录。
⼆进制⽇志（binary log） ：主要记
录的是更改数据库数据的 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 语
句执⾏的元数据操作。
⼆进制⽇志 binlog （归档⽇志）和事务
⽇志(redo log 和 undo log)⽐较重要，需
要我们重点关注。
慢查询⽇志记录了执⾏时间超过 long_q
uery_time （默认是 10s）的所有查
询，在我们解决 SQL 慢查询（SQL 执⾏
时间过⻓）问题的时候经常会⽤到。
慢查询⽇志默认是关闭的，我们可以通过
下⾯的命令将其开启：
long_query_time 参数定义了⼀个查
询消耗多⻓时间才可以被定义为慢查询，
默认是 10s，通过 SHOW VARIABLES L
IKE '%long_query_time%' 命令即可
查看：
并且，我们还可以对 long_query_time
参数进⾏修改：
在实际项⽬中，慢查询⽇志可能会⽐较
⼤，直接分析的话不太⽅便，我们可以借
助 MySQL 官⽅的慢查询分析调优⼯具
mysqldumpslow。
MySQL binlog(binary log 即⼆进制⽇志
⽂件) 主要记录了 MySQL 数据库中数据
的所有变化(数据库执⾏的所有 DDL 和
DML 语句)。
binlog 有⼀个⽐较常⻅的应⽤场景就是主
从复制，MySQL 主从复制依赖于 binlog
。另外，常⻅的⼀些同步 MySQL 数据到
其他数据源的⼯具（⽐如 canal）的底层
⼀般也是依赖 binlog 。
binlog 通过追加的⽅式进⾏写⼊，⼤⼩没
有限制。并且，我们可以通过 max_binl
og_size 参数设置每个 binlog ⽂件的最
⼤容量，当⽂件⼤⼩达到给定值之后，会
⽣成新的 binlog ⽂件来保存⽇志，不会
出现前⾯写的⽇志被覆盖的情况。
关于主从复制的具体步骤和原理，推荐看
看我写的读写分离&分库分表这篇⽂章。
我们知道 InnoDB 存储引擎是以⻚为单位
来管理存储空间的，我们往 MySQL 插⼊
的数据最终都是存在于⻚中的，准确点来
说是数据⻚这种类型。为了减少磁盘 IO
开销，还有⼀个叫做 Buffer Pool(缓冲
池) 的区域，存在于内存中。当我们的数
据对应的⻚不存在于 Buffer Pool 中的
话， MySQL 会先将磁盘上的⻚缓存到
Buffer Pool 中，这样后⾯我们直接操作
的就是 Buffer Pool 中的⻚，这样⼤⼤提
⾼了读写性能。
⼀个事务提交之后，我们对 Buffer Pool
中对应的⻚的修改可能还未持久化到磁
盘。这个时候，如果 MySQL 突然宕机的
话，这个事务的更改是不是直接就消失了
呢？
很显然是不会的，如果是这样的话就明显
违反了事务的持久性。
MySQL InnoDB 引擎使⽤ redo log 来保
证事务的持久性。redo log 主要做的事情
就是记录⻚的修改，⽐如某个⻚⾯某个偏
移量处修改了⼏个字节的值以及具体被修
改的内容是什么。redo log 中的每⼀条记
录包含了表空间号、数据⻚号、偏移量、
具体修改的数据，甚⾄还可能会记录修改
数据的⻓度（取决于 redo log 类型）。
在事务提交时，我们会将 redo log 按照
刷盘策略刷到磁盘上去，这样即使
MySQL 宕机了，重启之后也能恢复未能
写⼊磁盘的数据，从⽽保证事务的持久
性。也就是说，redo log 让 MySQL 具备
了崩溃回复能⼒。
不过，我们也要注意设置正确的刷盘策
略 innodb_flush_log_at_trx_commi
t ，根据 MySQL 配置的刷盘策略的不
同，MySQL 宕机之后可能会存在轻微的
数据丢失问题。
刷盘策略 innodb_flush_log_at_trx_
commit 的默认值为 1，设置为 1 的时候
才不会丢失任何数据。为了保证事务的持
久性，我们必须将其设置为 1。
下图是 MySQL 5.7 官⽅⽂档对于 innod
b_flush_log_at_trx_commit 参数的
详细介绍，我这⾥就不做过多阐述了。
redo log 采⽤循环写的⽅式进⾏写⼊，⼤
⼩固定，当写到结尾时，会回到开头循环
写⽇志，会出现前⾯写的⽇志被覆盖的情
况。
很多⼈可能要问了：为什么每次修改
Buffer Pool 中的⻚之后不直接刷盘呢？
这样不就不需要 redo log 了嘛！
这种⽅式必然是不⾏的，性能⾮常差。最
⼤的问题就是 InnoDB ⻚的⼤⼩⼀般为
16KB，⽽⻚⼜是磁盘和内存交互的基本
单位。这就导致即使我们只修改了⻚中的
⼏个字节数据，⼀次刷盘操作也需要将
16KB ⼤⼩的⻚整个都刷新到磁盘中。⽽
且，这些修改的⻚可能并不相邻，也就是
说这还是随机 IO。
采⽤ redo log 的⽅式就可以避免这种性
能问题，因为 redo log 的刷盘性能很
好。⾸先，redo log 的写⼊属于顺序
IO。 其次，⼀⾏ redo log 记录只占⼏⼗
个字节。
另外，Buffer Pool 中的⻚（脏⻚）在某
些情况下（⽐如 redo log 快写满了）也
会进⾏刷盘操作。不过，这⾥的刷盘操作
会合并写⼊，更⾼效地顺序写⼊到磁盘。
binlog 主要⽤于数据库还原，属于数
据级别的数据恢复，主从复制是
binlog 最常⻅的⼀个应⽤场景。
redolog 主要⽤于保证事务的持久
性，属于事务级别的数据恢复。
redolog 属于 InnoDB 引擎特有的，
binlog 属于所有存储引擎共有的，因
为 binlog 是 MySQL 的 Server 层实
现的。
redolog 属于物理⽇志，主要记录的
是某个⻚的修改。binlog 属于逻辑⽇
志，主要记录的是数据库执⾏的所有
DDL 和 DML 语句。
binlog 通过追加的⽅式进⾏写⼊，⼤
⼩没有限制。redo log 采⽤循环写的
⽅式进⾏写⼊，⼤⼩固定，当写到结
尾时，会回到开头循环写⽇志。
......
每⼀个事务对数据的修改都会被记录到
undo log ，当执⾏事务过程中出现错误或
者需要执⾏回滚操作的话，MySQL 可以
利⽤ undo log 将数据恢复到事务开始之
前的状态。
undo log 属于逻辑⽇志，记录的是 SQL
语句，⽐如说事务执⾏⼀条 DELETE 语
句，那 undo log 就会记录⼀条相对应的
INSERT 语句。
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
