mysql笔记系列(二)mysql更新和日志

1.日志文件（和更新息息相关）
redo log (重做日志)和bin log (归档日志) ，这两个是在sql进行更新的时候必定会涉及的。
mysql里面的wal技术 write-ahead logging ，先写磁盘日志 , 再写磁盘数据文件 。
也就是 innodB引擎，会先把更新写入到redo log里面，然后更新内容，等系统空闲的时候，再慢慢把redo log里面的内容 整理到磁盘数据文件里面。
但是如果redo log写满了， 那么就会触发 将redo log写入到磁盘文件里面的操作，将redo log腾出来一部分。
redo log 是固定大小的，从头开始写，写满了又会再次从头开始，有头尾两个指针表示当前的位置。
有了redo log 即使数据库突然挂了，也能恢复当时的数据记录。
redo log 是innoDB存储引擎特有的。
binlog（归档日志） 是server层的日志，和上面的区别就是 redo log是物理日志，记录的是对数据做了什么修改。
binlog是逻辑日志，记录的是这个语句的原始逻辑 比如说给某个列值+1 ， 可以理解成 一个记录的是操作结果，一个是记录的是操作过程。
且 redolog是循环写的，满了会覆盖旧的，但是binlog是追加写的，到了一定大小之后，会开启下一个。

7.更新的逻辑
1.执行器 ->调用存储引擎取数据
2.存储引擎 ->先搜索要更新的数据是否在内存中，如果不在，就从磁盘加载数据。
3.执行器对数据进行更新，然后->调用存储引擎将更新后的数据写入
4.存储引擎->将数据更新到内存，且记录redolog ， 状态为prepare , 返回结果给执行器
5.执行器->生成这个操作的binlog , 将binlog写入到磁盘, 通知存储引擎提交。
6.存储引擎 -> 将redolog 状态改为commit ，写入磁盘

这里是两阶段提交，先写redolog 状态为prepare ，然后写binlog 最后commit redolog 。
两阶段提交是为了保证，这两个日志的状态是一致的。

比如说
1.假设记录redolog ， 状态为prepare ，该阶段失败，那么后续的都不会执行。 数据等于没有修改。
2.假设生成这个操作的binlog , 将binlog写入到磁盘 该阶段失败，那么binlog没有写，且redolog未提交，也是无效，数据等于没有修改。
3.将redolog 状态改为commit 该阶段失败，那么恢复的时候，commit掉

假设 redolog和binlog是独立提交的，
那么出现redolog提交成功，binlog失败的情况， 根据binlog恢复的数据，就会比真正的数据少这个更改操作。
出现redolog提交失败，binlog成功，那么根据binlog恢复的数据，就会比真正的数据多了这个操作。

恢复数据是用的binlog ,而不是redolog
将c=1 改成了c=2，redolog里面 存的就是2，是结果，而且redolog大小是固定的，一般不会超过4G。而且这个本来设计出来就不会是为了备份的，只是充当写入的一个缓冲，先写到这里，然后后面慢慢更新到真正的数据文件上，假设删了半个月的数据，删除这个结果，已经被写入到了redolog里面，搞不好也已经被更新到了数据文件里面，是永久的，要恢复的时候，从半个月前的时间点，然后重放binlog，重放到现在，恢复这个数据

redolog 崩溃恢复+写入缓冲 binlog 数据备份