Java教程

第二讲 日志系统:一条SQL更新语句是如何执行的

本文主要是介绍第二讲 日志系统:一条SQL更新语句是如何执行的,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

redo log(重做日志)和 binlog(归档日志)

Write-Ahead Logging 写前日志技术
MySQL 里经常说到的 WAL 技术 Write-Ahead Logging,它的关键点就是先写日志,再写磁盘
先写入redo log,可以避免每次写磁盘低效的I/O,并且使用redo log日志还是顺序写入
InnoDB 的 redo log 是固定大小的,比如可以配置为一组 4 个文件,每个文件的大小是 1GB 0 1 2 3 循环使用

redo log bin log 对比
redo log 是 InnoDB 引擎特有的 它使InnoDB有crash safe能力,binlog 是 MySQL 的 Server 层实现的,所有引擎都可以使用。
redo log 是物理日志,记录的是“在某个数据页上做了什么修改”;binlog 是逻辑日志
redo log 是循环写的,空间固定会用完;binlog 是可以追加写入的

两阶段提交:redo log 和 binlog 都可以用于表示事务的提交状态,而两阶段提交就是让这两个状态保持逻辑上的一致。
update 语句:执行器先通过引擎获取要修改的行,将更新之后的数通过调用引擎接口写入这行新数据,引擎将这行新数据更新到内存中,同时将这个更新操作记录到 redo log 里面,此时 redo log 处于 prepare 状态,然后返回,执行器生成这个操作的 binlog,并把 binlog 写入磁盘。执行器调用引擎的提交事务接口,引擎把刚刚写入的 redo log 改成提交(commit)状态,更新完成。

不用两阶段提交 crash之后
先写 redo log 后写 binlog 少一行
先写 binlog 后写 redo log 由于事务回滚 恢复的备库多一行

这篇关于第二讲 日志系统:一条SQL更新语句是如何执行的的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!