概念，channgebuffer,减少IO次数。
它是一种应用在非唯一普通索引页(non-unique secondary index page)不在缓冲池中，对页进行了写操作，并不会立刻将磁盘页加载到缓冲池(从磁盘加载到缓冲池，需要进行随机读操作)，而仅仅记录缓冲变更(buffer changes)，等未来数据被读取时，再将数据合并(merge)恢复到缓冲池中的技术
适用于未加载到buffer pool 并且非唯一索引页
要理解change buffer还得先理解buffer pool是啥，顾名思义，硬盘在读写速度上相比内存有着数量级差距，如果每次读写都要从磁盘加载相应数据页，DB的效率就上不来，因而为了化解这个困局，几乎所有的DB都会把缓存池当做标配（在内存中开辟的一整块空间，由引擎利用一些命中算法和淘汰算法负责维护和管理），change buffer则更进一步，把在内存中更新就能可以立即返回执行结果(而不用从磁盘中将数据加载到内存中，随机读)并且满足一致性约束（显式或隐式定义的约束条件）的记录也暂时放在缓存池中(当然，这些也会进行持久化)，这样大大减少了磁盘IO操作的几率.
::我的理解
技巧💡
redo log 主要节省的是随机写磁盘的IO消耗（转成顺序写），而change buffer主要节省的则是随机读磁盘的IO消耗。
为什么说他是节省随机读磁盘的IO消耗呢？
因为changebuffer,是当前数据页不在缓冲池中，需要对数据进行操作时，将缓冲变更记录起来。减少了加载到缓存池的过程。我们知道，将数据加载到缓冲池，需要进行从磁盘进行随机读。如果没有change buffer, 执行更新的“当时那一刻”，就要求从磁盘把数据页读出来（这个操作是随机读）
简单来说，就是不直接写到磁盘，先写到日志顺序读写很快。为保证加载到bufferpool内存数据的准确性，就需要在后续读取时，进行merge操作。
merge操作(磁盘的数据不是最新的，需要与changebuffer进行合并恢复到缓冲池中，即)
技巧💡
- 如果内存有数据，内存数据一定是最新的，因为会先进行merge操作，此时会标记为脏页。保证最新。
- 真正对磁盘数据页的修改是通过将内存里脏页的数据刷回磁盘来完成的，而不是根据redolog。
- 脏页的数据，可能是已经在内存，直接变更导致脏数据，或者通过changebuffermerge的数据
- 原始数据页加载到 Buffer Pool 时
- 系统后台定时触发 merge 操作
- MySQL 数据库正常关闭时。
带changebuffer的更新过程
![[更新语句执行#:: 带 changebuffer 的更新过程 [ 1]]
持久化操作
触发持久化(Change Buffer 是 Buffer Pool 中的一部分,System Tablespace 中可以看到持久化 Change Buffer 的空间)
- 有一个后台线程，会认为数据库空闲时；
- 数据库缓冲池不够用时；
- 数据库正常关闭时
- redolog写满
突然宕机，changbuffer的数据怎么办？根据redolog来找回
redolog就是为了保证事务的持久性。因为change buffer是存在内存中的，万一机器重启，change buffer中的更改没有来得及更新到磁盘，就需要根据redo log来找回这些更新。 优点是减少磁盘I/O次数，即便发生故障也可以根据redo log来将数据恢复到最新状态。 缺点是会造成内存脏页，后台线程会自动对脏页刷盘，或者是淘汰数据页时刷盘，此时收到的查询请求需要等待，影响查询.
为什么redolog能恢复？💡
redolog不仅记录了数据的修改记录，也记录了changebuffer的数据
适用场景(写多读少，这样少merge)
适合写多读少的场景，因为这样即便立即写了，也不太可能会被访问到，延迟更新可以减少磁盘I/O，只有普通索引会用到，因为唯一性索引，在更新时就需要判断唯一性，所以没有必要。
参数
- innodb_change_buffer_max_size(占changbuffer最大大小 默认25% 最大 50%)
- innodb_change_buffering（哪些操作启用）
::QA
- 为什么changebuffer可以减少IO次数？都是写磁盘有什么区别吗？
如果没有change buffer, 执行更新的“当时那一刻”，就要求从磁盘把数据页读出来（这个操作是随机读）
- 为什么唯一索引用不了changebuffer?
因为唯一索引，需要在更新时判断唯一性，就没必要多次一举。判断唯一性要先加载到内存中。那么就没办法直接把变更写到日志中