MySQL写缓存Change Buffer原理与架构师必备技能详解
作为一种存储系统，MySQL同样配备了缓冲池（buffer pool）机制，旨在避免每次数据查询都触发磁盘IO操作。对于使用MySQL的开发者而言，深入理解InnoDB缓冲池的工作原理是架构师必备的知识。
免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈
在之前的《MySQL缓冲池（buffer pool）》一文中，我们详细介绍了InnoDB缓冲池的工作机制。
有一位名为童鞋的读者在评论区提问：对于读请求，MySQL缓冲池能够显著减少磁盘IO，提升系统性能。那么对于写请求，MySQL又是如何进行优化的呢？今天我们就来深入探讨这个问题。
首先，让我们简要回顾上一讲提到的缓冲池核心概念：
MySQL的数据存储包含内存与磁盘两个部分；内存缓冲池（buffer pool）以页为单位，缓存最热的数据页（data page）与索引页（index page）；InnoDB采用改进版LRU算法管理缓冲池，能够有效应对“预读失效”与“缓冲池污染”的问题；
当写请求到来时，会发生什么？
情况一
假设需要修改页码为4的索引页，而这个页面恰好在缓冲池内。
如上图步骤1-2所示：
直接修改缓冲池中的页面，这是一次内存操作；写入redo log，这是一次磁盘顺序写操作；
这样的处理效率是最高的。
画外音：类似日志顺序写入的场景，每秒数万次操作都能轻松应对。
是否会引发数据一致性问题？
完全不会。
读取操作会命中缓冲池中的页面；当缓冲池进行LRU数据淘汰时，会将“脏页”刷回磁盘；即使数据库异常崩溃，也能通过redo log恢复数据；
缓冲池中的页面何时会被刷入磁盘？
采用定期刷盘机制，而非每次修改都立即刷盘，能够有效降低磁盘IO，显著提升MySQL性能。
画外音：批量写入是常见的优化手段。
情况二
假设需要修改页码为40的索引页，而这个页面当前不在缓冲池内。
此时流程会稍微复杂一些，如上图需要完成步骤1-3：
先将页码40的索引页从磁盘加载到缓冲池，这是一次磁盘随机读操作；修改缓冲池中的页面，这是一次内存操作；写入redo log，这是一次磁盘顺序写操作；
当写请求未能命中缓冲池时，至少会产生一次磁盘IO。对于写多读少的业务场景，是否存在进一步的优化空间呢？
这正是InnoDB设计者考虑的问题，也是本文将要讨论的写缓冲（change buffer）机制。
画外音：从命名就可以看出，写缓冲是通过降低磁盘IO来提升数据库写入性能的一种技术手段。
什么是InnoDB的写缓冲？
在MySQL 5.5版本之前，这个功能称为插入缓冲（insert buffer），仅对insert操作进行优化；现在该机制对delete和update同样有效，因此更名为写缓冲（change buffer）。
它是一种应用于非唯一普通索引页（non-unique secondary index page）不在缓冲池中时，对页面进行写操作的优化技术。该机制不会立即将磁盘页加载到缓冲池，而是仅仅记录缓冲变更（buffer changes），等到未来数据被读取时，再将数据合并（merge）恢复到缓冲池中的技术。写缓冲的核心目的是降低写操作的磁盘IO，提升数据库整体性能。
画外音：这个句子确实写得有点长。
引入写缓冲优化后的流程变化
假设需要修改页码为40的索引页，而这个页面正好不在缓冲池内。
加入写缓冲优化后，流程简化为：
在写缓冲中记录这个操作，这是一次内存操作；写入redo log，这是一次磁盘顺序写操作；
此时性能表现与目标页面在缓冲池中时非常接近。
画外音：可以看到，40这个页面并没有被加载到缓冲池中。
此时是否会出现一致性问题？
同样不会。
即使数据库异常崩溃，也能从redo log中恢复数据；写缓冲不仅是一个内存结构，它也会被定期刷盘到写缓冲系统表空间；数据读取时，存在另外一个流程将数据合并到缓冲池；
不妨设想，稍后的某个时间，有请求需要查询索引页40的数据。
此时的流程如步骤1-3所示：
加载索引页面，缓冲池未命中，这次磁盘IO无法避免；从写缓冲读取相关信息；恢复索引页面，放到缓冲池LRU列表里；
画外音：可以看到，40这个页面只有在真正被读取时，才会被加载到缓冲池中。
还有一个遗留问题：为什么写缓冲优化仅适用于非唯一普通索引页？
在InnoDB中，聚集索引（clustered index）和普通索引（secondary index）存在本质差异，我们在之前的文章中已经详细讨论过，这里不再展开。
如果索引设置了唯一（unique）属性，在进行修改操作时，InnoDB必须进行唯一性检查。也就是说，即使索引页不在缓冲池中，磁盘上的页面读取也无法避免（否则如何校验是否唯一？），此时应该直接将要修改的页面放入缓冲池再进行变更，而不应该再使用写缓冲这个中间环节。
除了数据页被访问，还有哪些场景会触发写缓冲中的数据刷盘？
还存在以下几种情况，会促发写缓冲中的数据刷盘：
后台有一个专门的线程，会在数据库空闲时执行；当数据库缓冲池空间不足时；在数据库正常关闭时；当redo log写满时；
画外音：几乎不会出现redo log写满的情况，此时整个数据库将处于不可写入的不可用状态。
什么样的业务场景适合开启InnoDB的写缓冲机制？
先说说什么时候不适合，如上文分析，当：
数据库都是唯一索引；或者，在写入一个数据后，会立即读取它；
这两类场景在执行写操作时（进行后），本来就要进行页面读取，本来相应页面就要入缓冲池，此时写缓冲反倒成了负担，增加了复杂度。
什么时候适合使用写缓冲，比如：
数据库中大部分是非唯一索引；业务是写多读少，或者不是写后立即读取；
可以使用写缓冲，将原本每次写入都需要进行磁盘IO的SQL，优化为定期批量写磁盘。
画外音：例如，账单流水业务。
上述原理对应InnoDB中的哪些参数？
有两个比较重要的参数。
（1）参数：innodb_change_buffer_max_size
介绍：配置写缓冲的大小，占整个缓冲池的比例，默认值是25%，最大值是50%。
画外音：写多读少的业务，才需要调大这个值，读多写少的业务，25%其实也多了。
（2）参数：innodb_change_buffering
介绍：配置哪些写操作启用写缓冲，可以设置成all/none/inserts/deletes等。
写缓冲机制，你学明白了吗？
知其然，知其所以然。
思路比结论更重要。
相关攻略
Socket连接(准确说是Unix域套接字,Unix Domain Socket,UDS)是MySQL为本地进程间通信设计的专属连接方式，它并非网络协议，而是基于操作系统文件系统实现的进程通信机制。
新智元报道编辑：LRST【新智元导读】ContextBench首次从「过程」评测代码智能体，不再只看是否修好代码，而是追踪它是否精准找到并真正使用了关键代码片段，揭示了当前模型多读少用、被关键词误导
在之前的文章中，举了一个强制类型转换导致死锁的例子，有朋友询问是不是类型转换都不能命中索引，花1分钟细说一下。 《两个小公举，调试MySQL死锁必备！》中，举了一个强制类型转换导致死锁的例子，有朋友
MySQL 索引优化不用追求复杂，把以下五个基础技巧用熟，就能解决80%的索引问题。 MySQL索引优化是提升SQL查询效率的核心方法，用好索引能让慢查询“飞起来”，用不好反而会拖垮数据库。今天整理
今天和大家聊一个让无数 DBA 抓狂的问题：MySQL 异常宕机后，重启卡在 InnoDB。 今天想和大家聊一个让无数DBA抓狂的问题：MySQL异常宕机后，重启卡在“InnoDB: Startin
热门专题
热门推荐
末日生存手游推荐：前往九游开启你的废土冒险之旅 近年来，末日生存题材手游以其独特的沉浸感与生存挑战，持续吸引着大量玩家。在废墟世界中探索资源、应对危机、重建秩序的核心玩法，带来了紧张而富有成就感的游戏体验。如果你正在寻找一款高品质的末日生存手游，九游平台无疑是理想的起点。这里汇集了多款深受好评的末日
《纪念碑谷3》第二关“小镇”超详细图文攻略 《纪念碑谷》系列凭借其独特的视觉艺术与空间谜题设计广受赞誉。最新发布的《纪念碑谷3》在第二章节“小镇”中，将这一美学风格与机关逻辑提升到了新的层次。本章节不仅延续了标志性的极简主义美学，其空间层次感与交互严谨性也更具挑战性。本攻略将为你完整解析《纪念碑谷3
《生存33天》：“沙漠之王”高效通关攻略 在热门生存手游《生存33天》中，玩家面临的挑战远不止于无尽的丧尸潮。游戏深度结合了生存资源管理与高难度首领战策略，其中“沙漠之王”堪称游戏中期最具考验的BOSS。它不仅是实力分水岭，击败后更能获得稀有材料、限定头衔及海量经验金币，大幅推动队伍成长。本文将深入
《生存33天》“四只手”首领完全通关攻略 你是否在“四只手”首领关卡止步不前？不必焦虑，这个Boss在《生存33天》中素有“新秀杀手”之称。初次遭遇时，其独特的机制与高额伤害往往让玩家措手不及，不少冒险者在此耗费了数日时光。然而，只要掌握了它的核心规律，你就会发现这个敌人不过是外强中干。以下这份详尽
《剑与远征：启程》前排坦克英雄赫普深度解析：双形态切换机制与实战搭配指南 在《剑与远征：启程》这款策略放置手游中，组建一支攻守兼备的队伍至关重要，而前排坦克英雄的选择往往是决定胜败的关键。今天，我们将聚焦于蛮血部族的一位特色英雄——赫普。作为一名超稀有品质的坦克，赫普不仅具备坚实的防御力，更凭借独特