想和大家聊聊 InnoDB 中的锁机制，那么不可避免的要涉及到 MySQL 的日志系统，binlog、redo log、undo log 等，看到有小伙伴总结的这三个日志还不错，赶紧拿来和各位小伙伴分享。
日志是数据库的重要组成部分，记录着数据库运行期间各种状态信息。日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。
作为开发，我们重点需要关注的是二进制日志()和事务日志(包括和)，本文接下来会详细介绍这三种日志。
用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。是的逻辑日志，并且由层进行记录，使用任何存储引擎的数据库都会记录日志。
逻辑日志：可以理解为记录的就是sql语句.物理日志：数据最终是保存在数据页中的，物理日志记录的就是数据页变更 。
是通过追加的方式进行写入的，可以通过参数设置每个文件的大小，当文件大小达到给定值之后，会生成新的文件来保存日志。
在实际应用中，的主要使用场景有两个，分别是主从复制和数据恢复。
主从复制：在端开启，然后将发送到各个端，端重放从而达到主从数据一致。数据恢复：通过使用工具来恢复数据。
对于存储引擎而言，只有在事务提交时才会记录，此时记录还在内存中，那么是什么时候刷到磁盘中的呢？
通过参数控制的刷盘时机，取值范围是：
0：不去强制要求，由系统自行判断何时写入磁盘；1：每次的时候都要将写入磁盘；N：每N个事务，才会将写入磁盘。
从上面可以看出，最安全的是设置是，这也是之后版本的默认值。但是设置一个大一些的值可以提升数据库性能，因此实际情况下也可以将值适当调大，牺牲一定的一致性来获取更好的性能。
日志有三种格式，分别为、和。
在之前，默认的格式是，之后，默认值是。日志格式通过指定。
：基于 语句的复制( )，每一条会修改数据的sql语句会记录到 中 。：基于行的复制( )，不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了 。：基于 和 两种模式的混合复制( )，一般的复制使用 模式保存 ，对于 模式无法复制的操作使用 模式保存
我们都知道，事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。
那么是如何保证一致性的呢？
最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面：
因为是以为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了！一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差！
因此设计了，具体来说就是只记录事务对数据页做了哪些修改，这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。
包括两部分：一个是内存中的日志缓冲()，另一个是磁盘上的日志文件()。
每执行一条语句，先将记录写入，后续某个时间点再一次性将多个操作记录写到。这种先写日志，再写磁盘的技术就是
里经常说到的技术。
在计算机操作系统中，用户空间()下的缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统内核空间()缓冲区()。
因此，写入实际上是先写入，然后再通过系统调用将其刷到
中，过程如下：
支持三种将写入的时机，可以通过参数配置，各参数值含义如下：
前面说过，实际上记录数据页的变更，而这种变更记录是没必要全部保存，因此实现上采用了大小固定，循环写入的方式，当写到结尾时，会回到开头循环写日志。如下图：
同时我们很容易得知， 在innodb中，既有需要刷盘，还有也需要刷盘，存在的意义主要就是降低对刷盘的要求 ** 。
在上图中，表示当前记录的(逻辑序列号)位置，表示数据页更改记录刷盘后对应所处的(逻辑序列号)位置。
到之间的部分是空着的部分，用于记录新的记录；到之间是待落盘的数据页更改记录。当追上时，会先推动向前移动，空出位置再记录新的日志。
启动的时候，不管上次是正常关闭还是异常关闭，总是会进行恢复操作。因为记录的是数据页的物理变化，因此恢复的时候速度比逻辑日志(如)要快很多。
重启时，首先会检查磁盘中数据页的，如果数据页的小于日志中的，则会从开始恢复。
还有一种情况，在宕机前正处于的刷盘过程，且数据页的刷盘进度超过了日志页的刷盘进度，此时会出现数据页中记录的大于日志中的，这时超出日志进度的部分将不会重做，因为这本身就表示已经做过的事情，无需再重做。
由和的区别可知：日志只用于归档，只依靠是没有能力的。
但只有也不行，因为是特有的，且日志上的记录落盘后会被覆盖掉。因此需要和二者同时记录，才能保证当数据库发生宕机重启时，数据不会丢失。
数据库事务四大特性中有一个是原子性，具体来说就是原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。
实际上，原子性底层就是通过实现的。主要记录了数据的逻辑变化，比如一条语句，对应一条的，对于每个语句，对应一条相反的的，这样在发生错误时，就能回滚到事务之前的数据状态。
同时，也是(多版本并发控制)实现的关键。
到此这篇关于一文搞定MySQL binlog/redolog/undolog区别的文章就介绍到这了,更多相关mysql binlog/redolog/undolog区别内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
相关文章
