[MySQL]更新语句执行与redo log和bin log

前言：

如果问起来，你是否清楚sql的更新过程呢？

对于innodb，学习了它的更新过程。这个文章更像是我的个人学习笔记和感悟。下面进行简述。

对于log和更新的详情，以后还可以更深入一点。

1.更新的日志模块redo log(innoDB的log)

因为sql的更新并不是立即更新，因为更新要找到对应哪条的数据项，很慢。而且每一条在执行的时候都要去找到去改，很繁琐。

所以mysql都是放到log中，等空闲时候在进行执行。

这个redo log是一个类似于环形链表的结构。可以配置这个文件大小。

从头开始写，写到末尾然后再从头开始循环。

如果不够用了，就清理掉一些记录，然后把checkpoint推进以下(这个点可以理解为写入的点)

1.1 redo log具有crash-safe功能

就是如果突然crash掉，还可以保证数据的完整性。

 

mysql5.6开启了crash-safe功能，这个功能保护了异常断电等sql丢失的问题。

这个功能涉及到了数据库主从功能，Master/slave 同步。

2. 对于server层的binlog(归档日志)

特点：

对于所有引擎都通用。(所有的引擎都可以读懂，不像redolog只有innodb可以知道)

相对于redolog，这个是逻辑层的改动日志。(redolog是对于某个存储页(文件系统)做了什么改动)

Binlog有两种模式 ：  statement 格式的话是记sql语句，

                               row格式会记录行的内容，记两条，更新前和更新后都有。

redolog 是循环写，binlog 是追加写

binlog用来恢复数据库用，备份数据库进行整库备份，然后对于恢复到某一个时刻的数据，需要找到全量备份的最后时间点之后的binlog取出来，然后恢复数据。

3. 双重保险式--为什么有两个log？

因为最早mysql没有innoDB引擎，自带引擎MyISAM并没有这个日志功能。不能进行crash-safe；

redolog 更多是为了实现crash-safe 功能的。

更新语句的时候也相当于事务一样，

执行顺序： 先读取数据(在内存取出来，不在则磁盘读取)--执行更新操作--写入--先写入到内存中--写入redolog(进入准备状态)

--在写入binlog -- 最后一起提交进行commit状态

所以有点像事务，这两个log必须一起执行成功，不能有一个执行成功一个不成功；

4.总结

binlog在使用模式的时候一般都用row，因为库中可能会出现不一致的情况，row这种情况会记下来更新前和更新后。

物理速度是大于逻辑上的速度的。

redo log只有innodb有，别的引擎没有，redolog不是永久保存的，所以需要binlog作为归档功能，持久的保存数据，所以binlog并不能去掉。

redolog是顺序写(不需要去找位置，所以比较快，而更新到库里需要找位置)，并且是组提交，所以具有这两个特点带来的优势。

只有最后一步commit之后，才会真正提交写入到数据库中，但是数据库崩溃可以可以接受“redolog prepare 并且binlog完整” 的情况；

如果redolog 已经commit了，崩溃恢复就不需要去找binlog,如果没有commit 需要去找binlog进行事务恢复。

写数据到磁盘存储数据是随机写。