网站建设及优化教程,中国建设招投标网站,台州网站设计公司,phpwind的代表网站1. 背景
从 innodb 的整体架构中可以知道 innodb 的内存架构中分为 buffer pool 缓存区, change pool 修改缓冲区, adaptive hash index 自适应哈希索引, 和 log buffer 日志缓冲区. 2. buffer pool
buffer pool 是用于缓冲磁盘页的数据#xff0c;mysql 的80%的内存会分配给…1. 背景
从 innodb 的整体架构中可以知道 innodb 的内存架构中分为 buffer pool 缓存区, change pool 修改缓冲区, adaptive hash index 自适应哈希索引, 和 log buffer 日志缓冲区. 2. buffer pool
buffer pool 是用于缓冲磁盘页的数据mysql 的80%的内存会分配给 buffer pool 来使用。
当进行数据查询的时候如果数据页在buffer pool 中存在的话buffer pool 则直接返回如果不存在则会去从磁盘读取读取后再加载到磁盘中。
当有更新操作时更新 buffer pool 中的数据并且记录 redo log到了 checkpoint 点之后把内存中的脏页内存和磁盘数据不一致的页刷到磁盘上。
2.1. buffer pool 的数据结构
buffer pool 的内存结构中分为3种缓存页 和 3种链表缓存页分为 空闲页 free page干净页 clean page脏页 dirty page。链表分为 free list 当前没有被分配的内存页即 free page 组成的链表LRU list 读取到数据的内存页即干净页和脏页组成的链表flush list 脏页链表即脏页组成的链表这里需要注意在 flush list 中的页也存在与 LRU list 中。 2.2. free list
free list 定义是当前没有被使用的内存页也就是空闲的内存页当执行查询操作时如果页已经在 buffer pool 中了则查询到直接返回如果没有在 buffer pool并且 free list 不为空则会从磁盘中查询对应的数据放入 free list 的某一页中并且把这页从 free list 中移除放入 LRU 队列中。
2.3. LRU list
LRU list 顾名思义是使用了 LRU 算法当内存满的时候淘汰最久没有被使用的数据以释放内存空间来缓存最近使用的数据innoDB 在原有的 LRU 算法上做了优化把内存区域又分为了 new 和 old 2个部分默认配置是 37意味着 37% 的区域是 old63% 的区域是 new。 refhttps://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html 当有新的数据从磁盘查询到内存时会写入到 old sub list 的头部当此数据再次被查询的时候即在 old sublist 中命中之后会放入 new sublist 的头部。
这样做的目的是为了避免缓存中的热点数据被污染以提高缓存的命中率比如有一个sql select * from table没有设置过滤条件那大量的数据都会被加载到缓存中但是这种sql可能很长时间只跑一次在未来的一段时间内都不会再次查询如果不拆分 old 和 new会导致缓存的污染。
2.4. flush list
flush list 中保存的数据表示当前内存中的脏页的数量即 check point 刷盘的时候需要刷的脏页。
需要注意的是 flush list 中的数据在 LRU 中也会保存所以当 LRU 中的缓存被淘汰也会触发 flush list 中的脏页刷盘。
3. change bufferdouble write都是mysql 专用的 O:IMULRU list复制脏页进buffer pool
上面提到的 buffer pool 主要是用于提升 mysql 查询性能的mysql 写的性能提升提升主要依赖 change buffer以前 change buffer 称为 insert buffer因为以前只做了 insert 操作的性能优化之后版本更新之后也能对于修改和删除做缓存处理所以改名为 change buffer。
3.1. change buffer 解决的问题
我们假设现在有一张表其二级索引数据没有 load 到内存的 buffer pool 中我们对表进行更新操作那这个时候 innodb 会从磁盘中 load 数据出来到内存中这是第一次随机 IO 读取然后在内存进行 update 操作更新的字段如果涉及二级索引的更新需要再次读取二级索引的数据到内存中进行更新这是第二次随机读取的操作。那 change buffer 就是为了减少第二次随机 IO 读取以提高更新的效率。 change buffer 的思路是假设有很多次的更新但是没有查询二级索引的更新是可以批处理的一直等到下一次使用二级索引查询的时候把磁盘上的二级索引查询出来和 change buffer 中的索引修改的增量记录做 merge 之后在使用那磁盘的查询操作就会从多次变成一次了。
3.2. merge 是不是等于刷盘
merge 是指把 change buffer 中的增量变更在下一次查询的时候合并到 buffer pool 中从而这个 buffer pool 也变成了脏页。刷盘是指的是 buffer pool 中的脏页写到磁盘的过程这是两个事情。
3.3. 宕机会不会丢失
不会丢失因为事务提交的时候会写 redo logredo log 中会包含 change buffer 的内容如果出现宕机机器重启之后会基于 redo log 做重放可以恢复 change buffer。
3.4. 查看当前的change buffer
Ibuf: size 1, free list len 12, seg size 14, 1118 merges
merged operations:insert 1, delete mark 1117, delete 0
4. log buffer
log buffer 的作用是缓存 redo log 的写入操作考虑到一个大事务在事务期间可能会有很多次数据库操作不需要在事务中的每一次操作都写入 redo log可以缓存一定量的 redo log在合适的时间进行写盘。
合适的时间取决于 mysql 的配置0 1 2默认是 11是可以保证 ACID 的0 和 2 都有可能在极端情况下产生数据丢失。具体 0 1 2 的配置可见https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit
5. adaptive index
adaptive index 自适应哈希索引目的是为了提升索引的检索效率B 树的检索时间复杂度是 O(logn)生产上 B 树的深度一般是 3-4而 hash 索引的时间复杂度是 O(1)。
mysql 会默认开启自适应哈希索引基于mysql 的规则如果是符合自适应 hash 索引要求的会在 B 树的基础上建立自适应哈希索引。mysql 建立哈希索引必须是对于这个页的访问模式是一样的并且此处超过一定次数查询条件必须是等值条件查询比如 select * from table where a ? 或者是联合索引 where a? and b?。
5.1. adaptive index 锁的问题
因为自适应索引是针对于 B 树的索引进行优化涉及到索引的并发问题所以 mysql 更新自适应索引时需要获得锁在 5.7 之前只有一把锁有性能问题在之后的更新中加入了分片的概念默认分片是8个分片也就是8个锁提高了并行处理的能力。
5.2. 查看当前 mysql adaptive index
可以通过 show engine innodb status 语句来查看是否开启了自适应哈希索引。
可以看到下面的内容mysql 默认分片是8个分片所以看到有8块自适应哈希索引。
以及看到通过自适应哈希索引的查询效率是 0.09而不通过自适应哈希索引的即通过 B 树查询的效率是 0.15.
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:insert 0, delete mark 0, delete 0
discarded operations:insert 0, delete mark 0, delete 0
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 3 buffer(s)
0.09 hash searches/s, 0.15 non-hash searches/s
