MYSQL系列之 change buffer 和 redo log

读丁奇大佬课程笔记与思考 课程链接

WAL技术(Write-Ahead Logging) 先写日志，再写磁盘:

当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log（粉板）里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。
刚刚update的语句还在缓存中未持久化磁盘，此时select是直接读取内存

redo log

InnoDB的redo log固定大小，比如可配置一组四个文件，每个文件1G,有两个指针，write pos记录当前写位置，边写边后移，checkpoint记录当前更新到文件的位置。write pos追上checkpoint，表示满了，停下来进行部分保存。
有了redo log,InnoDB就可以保证即便数据库发生异常启动，之前的记录不会丢失，此能力叫 crash-safe

change buffer

当需要更新一个数据页时，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InnoDB 会将这些更新操作缓存在 change buffer 中，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。

注意:
1、唯一索引不会用到 change buffer，插入值时，会查询数据是否唯一，也就没有必要用change buffer，所以唯一索引一定意义上会影响性能(如果buffer pool上有数据)
2、适合写多读少的场景

插入一条数据的过程

插入一条数据: insert into t(id,k) values(id1,k1),(id2,k2);
假设当前 k 索引树的状态，查找到位置后，k1 所在的数据页在内存 (InnoDB buffer pool) 中，k2 所在的数据页不在内存中

分析这条更新语句，你会发现它涉及了四个部分：内存、redo log（ib_log_fileX）、 数据表空间（t.ibd）、系统表空间（ibdata1）。
这条更新语句做了如下的操作（按照图中的数字顺序）：
1、Page 1 在内存中，直接更新内存。
2、Page 2 没有在内存中，就在内存的 change buffer 区域，记录下“我要往 Page 2 插入一行”这个信息。
3、将上述两个动作记入 redo log 中（图中 3 和 4）。
做完上面这些，事务就可以完成了。所以，你会看到，执行这条更新语句的成本很低，就是写了两处内存，然后写了一处磁盘（两次操作合在一起写了一次磁盘），而且还是顺序写的。

查询一条语句的过程

1、读 Page 1 的时候，直接从内存返回。WAL 之后如果读数据，是不是一定要读盘，是不是一定要从 redo log 里面把数据更新以后才可以返回？其实是不用的。你可以看一下图 3 的这个状态，虽然磁盘上还是之前的数据，但是这里直接从内存返回结果，结果是正确的。
2、要读 Page 2 的时候，需要把 Page 2 从磁盘读入内存中，然后应用 change buffer 里面的操作日志，生成一个正确的版本并返回结果。
可以看到，直到需要读 Page 2 的时候，这个数据页才会被读入内存。
所以，如果要简单地对比这两个机制在提升更新性能上的收益的话，redo log 主要节省的是随机写磁盘的 IO 消耗（转成顺序写），而 change buffer 主要节省的则是随机读磁盘的 IO 消耗。