MySQL实战学习（二）
redo log
当数据库有一条记录需要更新时，InnoDB引擎会先把记录写到redolog中，同时更新内存。这个时候就算是更新完成了，同时，InnoDB会在适当时刻将这个操作记录更新到磁盘里面。InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写，如下面这个图所示。
当空间写满时，也就是写指针追上检查指针后，就要停下所有的更新操作，先擦除一部分数据，再把检查指针推进。
这个redolog可以保证数据库发生异常重启时，之前提交的记录不会丢失，这种能力叫做crash-safe
TIPS:CPU在进行复杂运算时会把中间数据存储到它的缓存中，而当CPU缓存满了的时候，缓存会与RAM进行数据同步，他们之间同过脏位dirty-bit来区分哪些数据需要进行更新，个人感觉思想上这两者差不多，同时我也了解一个一种缓存的更新策略，Write Behind Caching 更新模式。Write Back 套路就是，在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的 I/O 操作飞快无比（因为直接操作内存嘛）。因为异步，Write Back 还可以合并对同一个数据的多次操作，所以性能的提高是相当可观的。
binlog
对比一下两种日志有以下三点不同。
- redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
- redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
- redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
Binlog有两种模式，statement 格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有。
保证数据库的一致性，必须要保证2份日志一致，使用的2阶段式提交；其实感觉像事务，不是成功就是失败，不能让中间环节出现，也就是一个成功，一个失败
以上是 MySQL实战学习（二） 的全部内容， 来源链接： utcz.com/z/512956.html
