在做SQL数据更新的时候,往往会设计两个重要的日志模块-
redo log
以及binlog
1、redo log
redo log是InnoDB引擎上特有的日志。
①为什么需要redo log?
因为在MySQL中,如果每次更新都立刻写进磁盘,磁盘是需要去到更新对应的表找到对应的记录进行修改。这个过程中的IO操作和查找操作都需要比较长的时间,这在更新操作频繁的系统里显然是效率低下的。
所以为了解决这个问题,MySQL设计者使用了WAL 技术(Write-Ahead Logging)
来解决这个问题,就是先写日志,等到系统比较空闲的时候,再写磁盘。具体的过程就是,当一条记录需要被更新时,InnoDB 引擎会先把记录写到 redo log里面,并更新内存,然后InnoDB 引擎会在“空闲”的时候,将这个操作记录更新到磁盘里面。
- 注意:redo log的大小是固定的,如果日志写满了,就需要先把日志的一部分操作更新到磁盘里,然后才可以继续写入日志。
②redo log有什么作用?
有redo log
的InnoDB可以保证即使数据库发生异常重启,之前提交的记录都不会丢失,这个能力称为 crash-safe
。
2、binlog
redo log是InnoDB引擎层里特有的日志,而binlog是Server层里的归档日志。
①已经有redo log了为什么还需要binlog?
首先是因为binlog的出现是比redo log更早,后来出现InnoDB引擎后,又因为 binlog 是没有 crash-safe 能力,所以 InnoDB 引入了redo log这个日志系统。
②binlog与redo log的不同
- redo log 是 InnoDB 引擎特有的;binlog 是 MySQL 的 Server 层实现的,所有引擎都可以使用。
- redo log 是物理日志,记录的是“在某个数据页上做了什么修改”;binlog 是逻辑日志,记录的是这个语句的原始逻辑。
- redo log 是循环写的,空间固定会用完;binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。
注意:Binlog有两种模式:
statement
格式是记sql语句row
格式是记录行的内容,会记录两条数据,分别是数据修改前后的样子。
3、执行更新语句时的流程
例如,在我们的数据库里执行UPDATE user SET username="tony" WHERE id=4;
时,更新的流程是怎样的呢?
- 先是通过客户端与服务端通过连接器建立连接后,通过分析器进行词语分析、语法分析以及优化器选定执行方案等一系列操作后,来到执行器,执行器通过引擎接口找到user表里id为4的那一条记录,如果这一条记录所在的数据页已经是从磁盘读取到内存的话,就可以直接返回给执行器,不然就需要先从磁盘读取到内存,再返回。
- 执行器拿到引擎给的行数据,把这个值改为tony,得到新的一行数据,再调用引擎接口写入这行新数据。
- 引擎将这行新数据更新到内存中,同时将这个更新操作记录到 redo log 里面,此时 redo log 处于 prepare 状态。然后告知执行器执行完成了,随时可以提交事务。
- 执行器生成这个操作的 binlog,并把 binlog 写入磁盘。
- 执行器调用引擎的提交事务接口,引擎把刚刚写入的 redo log 改成提交(commit)状态,更新完成。
为什么 redo log拆分成了两个步骤提交(prepare&commit)?
因为不分成两个步骤提交,会可能是的数据库的状态与用它的日志恢复出来的库的数据不一致。
总结
- redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候,表示每次事务的 redo log 都直接持久化到磁盘。
- sync_binlog 这个参数设置成 1 的时候,表示每次事务的 binlog 都持久化到磁盘。
注:该文章为本人的总结笔记,详细原文建议阅读MySQL45讲