标签：缓存 log Buffer 更新 索引 MySQL45 redo Change

前言

本文介绍MySQL的更新缓存Change Buffer，以及唯一索引和普通索引如何选择。

唯一索引和普通索引的选择

查询过程

唯一索引下，查询索引树，找到第一条匹配的行就返回；
普通索引下，查询索引树，找到第一条匹配的行之后，继续往下遍历，直到第一条不匹配的行为止，再返回。

即使匹配的行跨了数据页，但一个数据页默认16KB，每行只存储一个key且是整数，可以存储近千个。那么普通索引下，最多也是多加载一次数据页。所以唯一索引和普通索引的查询效率基本相同。

更新过程

首先介绍下MySQL的更新缓存Change Buffer，它使用的是MySQL Buffer Pool的存储空间，可以设置Change Buffer在Buffer Pool中的占比，MySQL5.6默认为25%，最多可以开到50%。

顾名思义，Change Buffer就是用来存储更新操作的，使得更新操作不需要加载对应的数据页，直接更新到内存。当对Change Buffer中的行进行查询时，就会将原始数据页加载到内存，并将缓存应用到原始数据页，这个就是merge过程。Change Buffer的merge触发时机：

• 当原始数据页加载到Buffer Pool时
• 后台线程定期merge
• 数据库正常关闭时

Change Buffer的刷盘触发时机：

• 数据库空闲时，会定时持久化
• 数据库缓冲不够用时
• 数据库正常关闭之前
• redo log写满时

你或许会疑问“万一在刷盘之前数据库宕机了，那之前的更新不就丢失了么？”

答案是否。简单分析是，因为将更新操作写到Change Buffer后，还会将更新操作写到redo log并持久化到磁盘，数据库宕机重启之后，会将之前的更新缓存数据恢复到内存。

具体分析如下：
（1）change buffer写入,redo log虽然做了fsync但未commit,binlog未fsync到磁盘,这部分数据丢失

（2）change buffer写入,redo log写入但没有commit,binlog以及fsync到磁盘,先从binlog恢复redo log,再从redo log恢复change buffer

（3）change buffer写入,redo log和binlog都已经fsync.那么直接从redo log里恢复。

接下来分析两种索引下的更新操作：
唯一索引下，查询索引树，加载对应的数据页到内存，判断是否违反一致性约束，再更新；
普通索引，查询索引树，直接更新内存中的Change Buffer。

因为唯一索引需要判断更新操作是否违反一致性约束，所以必须加载数据页，也就用不到Change Buffer，即Change Buffer只用于普通索引。

从上面的分析可见，在更新多于读取操作的情况下，普通索引的更新操作效率要高于唯一索引。但如果是更新之后就有查询的场景，那么Change Buffer不但没有起到提效作用，反而占用的缓冲空间。所以，这种情况下，一般会关闭Change Buffer来避免它的副作用。

总结

总结来说，如果业务需要数据库来对数据进行唯一性约束，那么优先还是考虑唯一索引；否则，如果是更新远多于读取操作的业务场景，比如归档，日志等，考虑用普通索引代替唯一索引，可以提高内存命中率和提高更新效率。但如果是更新之后就有查询的场景，则建议关闭Change Buffer，来避免它的副作用。

标签：缓存,log,Buffer,更新,索引,MySQL45,redo,Change
来源： https://www.cnblogs.com/flowers-bloom/p/mysql45-change-buffer.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。