14.4.2 Change Buffer 延迟写

14.4.2 Change Buffer

change buffer 是一个特殊的数据结构 用于cahce 改变的secondary index pages

当被影响的pages 不在buffer pool里,buffered changes, 可能是由于 INSERT, UPDATE, or DELETE 操作(DML)

是随后合并 当pages是被君子爱到Buffer pool通过其他读操作

不像clustered indexes,secondary indexes  通常不是非唯一的,

插入到  secondary indexes 发生一个相对随机的顺序。

类似的,删除和更新可能影响secondary index pages 不相邻的位于一个索引树立。

合并cached changes 在随后的时间,当影响的Page被读入到buffer pool通过其他操作,

避免随机的I/O 需要被读在secondary index pages 


周期性的, purge 操作运行当系统是空闲时, 或者在一个slow shutdown ,


写更新的index pages 到磁盘。 purge 操作可以写磁盘块对于一些列的Index 值相比如果每个值被理解写入到磁盘更加有效率


Change buffer 合并可能需要几个小时 当有大量的secondary indexes需要更新和影响了很多行。

在这个期间,disk I/O 是在增加,可以导致 一个显著的slowdown 对于磁盘查询

Change buffer merging 也会继续发生在一个事务被提交时。


Change buffer merging  类似Oracle的机制 数据提交先写redo 写数据文件延迟写

在内存里, change buffer 占据了InnoDB buffer pool的一部分。在磁盘上,

change buffer 是系统表空间的一部分, 因此index changes 保留换成在数据库重启启动时



mysql> show variables like '%innodb_change_buffering%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| innodb_change_buffering | all   |
+-------------------------+-------+
1 row in set (0.00 sec)

InnoDB是否 执行change buffering,一个优化的是延迟写操作到secondary indexes

这样I/O操作可以被顺序执行

转载于:https://www.cnblogs.com/zhaoyangjian724/p/6199096.html

你可能感兴趣的:(14.4.2 Change Buffer 延迟写)