MySQL系统架构

最近在准备给新人培训,对于DBA相关的新人,最推荐的莫过于学习官方文档,像Oracle的concept,MySQL的reference等,MySQL被Oracle收购以后,文档也越来越完整和形象,对于刚学习的新人,学习官方文档有助于跟为系统得学习。

本篇主要讲MySQL8.0InnoDB的架构。

跟其他关系型数据库一样,MySQL的架构也分为In-Memory 和On-Disk两部分。
MySQL系统架构
在内存结构中,主要由4大块组成。

Buffer Pool(以下简称bp)

bp在整个内存中占绝大多数,MySQL官方一般建议设置为服务器物理内存的80%。这边建议MySQL整体内存控制在80%左右,bp最好不要超过70%,不然容易OOM。
理解了bp的原理,对于数据库也有差不多理解了一半了。bp主要结构是个list,用的是LRU算法的变种(least recently used)。
主要用来缓存数据块(page,也叫页),mysql默认为16k,oracle为8k。如果内存达到了阈值,那么就会把最近最少使用到的page驱逐(evicted)出内存。然后把新页插入到中间位置,一般为整条list的热端5/8处。
查看下图可以看到,整个bp分为两个sublist,上端为热端,缓存热点数据(频繁被访问);另外一端为冷端,随时被驱逐出内存。
也正是因为磁盘访问数据不如内存,才有了bp的存在,大家也可以想象一下,如果磁盘数据比内存快,还有bp存在的价值吗?
所有用户访问的数据,都要先经过bp,但如果走全表扫描,按道理也有把数据缓存在bp中,那么势必会把大量数据驱逐出去,当然我们也可以通过调整参数来优化,这个我们在这篇知识普及文档中暂不提及。
可以通过设置 innodb_buffer_pool_size来调整bp的大小,可以在实例启动前在my.cnf中配置,也可以在实例运行中动态设置。
并且可以通过设置innodb_buffer_pool_instances的数量来调整bp池的数量,有利于减少LRU mutex的争议和扫描量,最近刚好有碰到这个bug:
https://bugs.mysql.com/bug.php?id=98869。如果是运行中动态设置bp,还可以通过监控 Innodb_buffer_pool_resize_status参数来查看resize的状态(也同样会写到error log中);如果是增大bp,则会增加chunks数量和page,覆盖hash table和list,并且指针指向内存中新的地址,增加新页到free list;如果是减少bp,则释放和重组bp,在chunks中移除page,覆盖hash table和list,并且指针指向内存中新的地址。
可以通过运行: SHOW ENGINE INNODB STATUS,在BUFFER POOL AND MEMORY部分看到bp相关统计数据。
MySQL系统架构
附:https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html

Change Buffer(以下简称cb)

cp是mysql内存结构中比较特殊的一个,它是用来缓存不在bp中的二级索引(secondary index,相对于cluster index来说)变化的page,是DML的结果,并定期合并、读到bp中。二级索引可以值是不唯一的,cp也是占用bp的内存,在shutdown 实例以后,会成为系统表空间的一部分。cp存在的意义是为了在执行DML的时候,异步二级索引的写入,到达尽可能的顺序写,提高IO效率,对I/O-bound型有一定优化作用。可以通过设置 innodb_change_buffering来控制什么类型的DML能够在cp中。通过innodb_change_buffer_max_size来设置在bp中占用的百分比。可以通过show engine innodb status中的INSERT BUFFER AND ADAPTIVE HASH INDEX 来监控cp相关数据统计。
MySQL系统架构

Adaptive Hash Index

mysql本身不支持哈希索引,但内部有使用到自适哈希索引,维护hash表。可以通过 innodb_adaptive_hash_index 来启用,也可以动态修改。
hash index通过B-TREE索引键前缀创建,基于需求和最经常访问的搜索pattern。mysql基于自己的算法来自行创建哈希索引,并且hash table是分区的,通过控制innodb_adaptive_hash_index_parts来设置分区数量,在特定情况下可以启动加速查询的效果,对like和%不友好。

Redo Log Buffer

redo log buffer也是基本所有关系型数据库都有的,redo log也叫 WAL,用来缓存数据变化,在脏数据flush到数据文件前,需要先写入到redo log buffer,再写入到redo log中,一个目的是用来保证数据一致性,保证数据库crash以后能够通过redo log进行恢复。第二个主要用来降低IO,如果每次数据库的DML都直接写入到数据文件中,则会大大影响性能。可以通过innodb_log_buffer_size来控制内存大小,默认为16M。定期有线程对齐进行flush,确保更新都刷入到redo log中,并且redo log的page size为512k,也就是一个扇区的大小,并且是顺序写,保证了性能和一致性,不至于需要double write.通过设置innodb_flush_log_at_trx_commit=1来获得ACID的保证,每次事务提交马上flush到redo log,如果对数据一致性不严格的,可以通过设置0来定期刷新,提高性能。定期刷新可以通过设置innodb_flush_log_at_timeout来控制,默认为1秒钟。

至此mysql内存相关的4个主要的组成部分已经讲完,另外还有很多小的内存区域,比如由来缓存数据字典等,以后碰到再讲,接着会介绍mysql on-disk部分的架构。
https://yq.aliyun.com/articles/764516?spm=a2c4e.11155435.0.0.71de331269m7Gf

上一篇:使用TestNG-xslt美化测试报告


下一篇:SourceTree的简单使用