1、前序1
在《MySQL存储引擎之InnoDB - 缓冲池(buffer pool)》中提到:
(1)MySQL数据存储包含内存与磁盘两个部分;
(2)内存缓冲池(buffer pool)以页为单位,缓存最热的数据页(data page)与索引页(index page);
(3)InnoDB以变种LRU算法管理缓冲池,并能够解决【预读失效】与【缓冲池污染】的问题;
毫无疑问,对于读请求,缓冲池能够减少磁盘IO,提升性能。问题来了,那写请求呢?
2、场景1:访问页命中缓冲池
假如要修改页号为4的索引页,而这个页正好在缓冲池内。
如上图:
(1)直接修改缓冲池中的页,一次内存操作;
(2)写入redo log,一次磁盘顺序写操作;
这样的效率是最高的。像写日志这种顺序写,每秒几万次没问题。
- 数据一致性问题(不存在)
(1)读取,会命中缓冲池的页;
(2)缓冲池LRU数据淘汰,会将“脏页”刷回磁盘;
(3)数据库异常奔溃,能够从redo log中恢复数据; - 缓冲池中的页刷新到磁盘的时机
定期刷磁盘,而不是每次刷磁盘。能够降低磁盘IO,提升MySQL的性能。(批量写,是常见的优化手段)
3、场景2:访问页未命中缓冲池
假如要修改页号为40的索引页,而这个页正好不在缓冲池内。
此时麻烦一点,如上图需要1-3:
(1)先把页号为40的索引页,从磁盘加载到缓冲池,一次磁盘随机读操作;
(2)修改缓冲池中的页,一次内存操作;
(3)写入redo log,一次磁盘顺序写操作;
没有命中缓冲池的时候,至少产生一次磁盘IO,对于写多读少的业务场景,是否还有优化的空间呢?
4、写缓冲2
它应用在非唯一普通索引页(non-unique secondary index page),而不在缓冲池中,对页进行了写操作。
数据的写操作并不会立刻将磁盘页加载到缓冲池,而仅仅记录缓冲变更(buffer changes)。
当未来数据被读取时,再将数据合并(merge)恢复到缓冲池中的技术。写缓冲的目的是降低写操作的磁盘IO,提升数据库性能。
- InnoDB加入写缓冲优化,上文“情况二”流程会有什么变化?
假如要修改页号为40的索引页,而这个页正好不在缓冲池内。 - 加入写缓冲优化后,流程优化为:
(1)在写缓冲中记录这个操作,一次内存操作;
(2)写入redo log,一次磁盘顺序写操作;
可以看到,40这一页并没有加载到缓冲池中。其性能与场景1相近。
不妨设,稍后的一个时间,有请求查询索引页40的数据。 - 此时的流程如序号1-3:
(1)载入索引页,缓冲池未命中,这次磁盘IO不可避免;
(2)从写缓冲读取相关信息;
(3)恢复索引页,放到缓冲池LRU里;
可以看到,40这一页,在真正被读取时,才会被加载到缓冲池中。 - 数据一致性问题(不存在)
(1)数据库异常奔溃,能够从redo log中恢复数据;
(2)写缓冲不只是一个内存结构,它也会被定期刷盘到写缓冲系统表空间;
(3)数据读取时,有另外的流程,将数据合并到缓冲池; - 为什么写缓冲优化,仅适用于非唯一普通索引页呢?
如果索引设置了唯一(unique)属性,在进行修改操作时,InnoDB必须进行唯一性检查。也就是说,索引页即使不在缓冲池,磁盘上的页读取无法避免(否则怎么校验是否唯一?),此时就应该直接把相应的页放入缓冲池再进行修改,而不应该再整写缓冲这个幺蛾子。 - 会刷写缓冲中的数据的几种情况:
(1)上文提到,数据页被访问的时候;
(2)有一个后台线程,会认为数据库空闲时;
(3)数据库缓冲池不够用时;
(4)数据库正常关闭时;
(5)redo log写满时(几乎不会出现,否则整个数据库处于无法写入的不可用状态);
5、写缓冲使用场景
- 什么业务场景,不适合开启InnoDB的写缓冲机制?
(1)数据库都是唯一索引;
(2)或者,写入一个数据后,会立刻读取它;
这两类场景,在写操作进行时(进行后),本来就要进行进行页读取,本来相应页面就要入缓冲池,此时写缓存反倒成了负担,增加了复杂度。 - 什么业务场景,适合开启InnoDB的写缓冲机制?
(1)数据库大部分是非唯一索引;
(2)业务是写多读少,或者不是写后立刻读取;
可以使用写缓冲,将原本每次写入都需要进行磁盘IO的SQL,优化定期批量写磁盘。例如:账单流水业务。
6、写缓冲参数配置
-
innodb_change_buffer_max_size
配置写缓冲的大小,占整个缓冲池的比例,默认值是25%,最大值是50%。
写多读少的业务,才需要调大这个值,读多写少的业务,25%其实也多了。 -
innodb_change_buffering
配置哪些写操作启用写缓冲,可以设置成all/none/inserts/deletes等。
# 脚注
- 本文转载自博客《写缓冲(change buffer),这次彻底懂了!!》,并在学习的过程中对其进行了重新排版。 ↩︎
- 在MySQL5.5之前,叫插入缓冲(insert buffer),只针对insert做了优化;现在对delete和update也有效,叫做写缓冲(change buffer)。 ↩︎