网站首页代码怎么做,自动免费设计logo,灵宝市建设局网站,页面设计属于作品登记的哪个类别缓存的重要性
我们知道#xff0c;对于使用InnoDB作为存储引擎的表来说#xff0c;不管是用于存储用户数据的索引#xff08;包括聚簇索引和二级索引#xff09;#xff0c;还是各种系统数据#xff0c;都是以页的形式存放在表空间中的#xff0c;而所谓的表空间只不过…缓存的重要性
我们知道对于使用InnoDB作为存储引擎的表来说不管是用于存储用户数据的索引包括聚簇索引和二级索引还是各种系统数据都是以页的形式存放在表空间中的而所谓的表空间只不过是InnoDB对文件系统上一个或几个实际文件的抽象也就是说我们的数据说到底还是存储在磁盘上的。但是各位也都知道磁盘的速度慢的跟乌龟一样怎么能配得上“快如风疾如电”的CPU呢所以InnoDB存储引擎在处理客户端的请求时当需要访问某个页的数据时就会把完整的页的数据全部加载到内存中也就是说即使我们只需要访问一个页的一条记录那也需要先把整个页的数据加载到内存中。将整个页加载到内存中后就可以进行读写访问了在进行完读写访问之后并不着急把该页对应的内存空间释放掉而是将其缓存起来这样将来有请求再次访问该页面时就可以省去磁盘IO的开销了。
InnoDB的Buffer Pool
设计InnoDB的大佬为了缓存磁盘中的页在MySQL服务器启动的时候就向操作系统申请了一片连续的内存他们给这片内存起了个名叫做Buffer Pool中文名是缓冲池。
Buffer Pool内部组成
Buffer Pool中默认的缓存页大小和在磁盘上默认的页大小是一样的都是16KB。为了更好的管理这些在Buffer Pool中的缓存页设计InnoDB的大佬为每一个缓存页都创建了一些所谓的控制信息这些控制信息包括该页所属的表空间编号、页号、缓存页在Buffer Pool中的地址、链表节点信息、一些锁信息以及LSN信息锁和LSN我们之后会具体介绍现在可以先忽略当然还有一些别的控制信息我们这就不全介绍一遍了挑重要的说嘛
每个缓存页对应的控制信息占用的内存大小是相同的我们就把每个页对应的控制信息占用的一块内存称为一个控制块吧控制块和缓存页是一一对应的它们都被存放到 Buffer Pool 中其中控制块被存放到 Buffer Pool 的前面缓存页被存放到 Buffer Pool 后边所以整个Buffer Pool对应的内存空间看起来就是这样的
free链表的管理
当我们最初启动MySQL服务器的时候需要完成对Buffer Pool的初始化过程就是先向操作系统申请Buffer Pool的内存空间然后把它划分成若干对控制块和缓存页。但是此时并没有真实的磁盘页被缓存到Buffer Pool中因为还没有用到之后随着程序的运行会不断的有磁盘上的页被缓存到Buffer Pool中。那么问题来了从磁盘上读取一个页到Buffer Pool中的时候该放到哪个缓存页的位置呢或者说怎么区分Buffer Pool中哪些缓存页是空闲的哪些已经被使用了呢我们最好在某个地方记录一下Buffer Pool中哪些缓存页是可用的这个时候缓存页对应的控制块就派上大用场了我们可以把所有空闲的缓存页对应的控制块作为一个节点放到一个链表中这个链表也可以被称作free链表或者说空闲链表。刚刚完成初始化的Buffer Pool中所有的缓存页都是空闲的所以每一个缓存页对应的控制块都会被加入到free链表中假设该Buffer Pool中可容纳的缓存页数量为n那增加了free链表的效果图就是这样的
缓存页的哈希处理
我们前面说过当我们需要访问某个页中的数据时就会把该页从磁盘加载到Buffer Pool中如果该页已经在Buffer Pool中的话直接使用就可以了。那么问题也就来了我们怎么知道该页在不在Buffer Pool中呢 难不成需要依次遍历Buffer Pool中各个缓存页么一个Buffer Pool中的缓存页这么多都遍历完岂不是要累死
再回头想想我们其实是根据表空间号 页号来定位一个页的也就相当于表空间号 页号是一个key缓存页就是对应的value怎么通过一个key来快速找着一个value呢那肯定是希表喽 所以我们可以用表空间号 页号作为key缓存页作为value创建一个哈希表在需要访问某个页的数据时先从哈希表中根据表空间号 页号看看有没有对应的缓存页如果有直接使用该缓存页就好如果没有那就从free链表中选一个空闲的缓存页然后把磁盘中对应的页加载到该缓存页的位置。
flush链表的管理
如果我们修改了Buffer Pool中某个缓存页的数据那它就和磁盘上的页不一致了这样的缓存页也被称为脏页英文名dirty page。当然最简单的做法就是每发生一次修改就立即同步到磁盘上对应的页上但是频繁的往磁盘中写数据会严重的影响程序的性能毕竟磁盘慢的像乌龟一样。所以每次修改缓存页后我们并不着急立即把修改同步到磁盘上而是在未来的某个时间点进行同步至于这个同步的时间点我们后边会作说明说明的现在先不用管
但是 如果不立即同步到磁盘的话那之后再同步的时候我们怎么知道 Buffer Pool 中哪些页是脏页哪些页从来没被修改过呢 总不能把所有的缓存页都同步到磁盘上吧假如 Buffer Pool 被设置的很大比方说300G那一次性同步这么多数据岂不是要慢死所以我们不得不再创建一个存储脏页的链表凡是修改过的缓存页对应的控制块都会作为一个节点加入到一个链表中因为这个链表节点对应的缓存页都是需要被刷新到磁盘上的所以也叫flush链表。链表的构造和free链表差不多假设某个时间点Buffer Pool中的脏页数量为n那么对应的flush链表就长这样
LRU链表的管理
当Buffer Pool中不再有空闲的缓存页时就需要淘汰掉部分最近很少使用的缓存页。不过我们怎么知道哪些缓存页最近频繁使用哪些最近很少使用呢 呵呵神奇的链表再一次派上了用场我们可以再创建一个链表由于这个链表是为了按照最近最少使用的原则去淘汰缓存页的所以这个链表可以被称为LRU链表LRU的英文全称Least Recently Used。当我们需要访问某个页时可以这样处理LRU链表
如果该页不在Buffer Pool中在把该页从磁盘加载到Buffer Pool中的缓存页时就把该缓存页对应的控制块作为节点塞到链表的头部。
如果该页已经缓存在Buffer Pool中则直接把该页对应的控制块移动到LRU链表的头部。
也就是说只要我们使用到某个缓存页就把该缓存页调整到LRU链表的头部这样LRU链表尾部就是最近最少使用的缓存页喽 所以当Buffer Pool中的空闲缓存页使用完时到LRU链表的尾部找些缓存页淘汰就OK啦真简单啧啧…
划分区域的LRU链表
上面的这个简单的LRU链表用了没多长时间就发现问题了因为存在这两种比较尴尬的情况 情况一InnoDB提供了一个看起来比较贴心的服务——预读英文名read ahead。所谓预读就是InnoDB认为执行当前的请求可能之后会读取某些页面就预先把它们加载到Buffer Pool中。根据触发方式的不同预读又可以细分为下面两种
线性预读
设计InnoDB的大佬提供了一个系统变量innodb_read_ahead_threshold如果顺序访问了某个区extent的页面超过这个系统变量的值
就会触发一次异步读取下一个区中全部的页面到Buffer Pool的请求注意异步读取意味着从磁盘中加载这些被预读的页面并不会影响到当前工作线程的正常执行。
这个innodb_read_ahead_threshold系统变量的值默认是56我们可以在服务器启动时通过启动参数或者服务器运行过程中直接调整该系统变量的值
不过它是一个全局变量注意使用SET GLOBAL命令来修改哦。随机预读
如果Buffer Pool中已经缓存了某个区的13个连续的页面不论这些页面是不是顺序读取的都会触发一次异步读取本区中所有其的页面到Buffer Pool的请求。
设计InnoDB的大佬同时提供了innodb_random_read_ahead系统变量它的默认值为OFF也就意味着InnoDB并不会默认开启随机预读的功能
如果我们想开启该功能可以通过修改启动参数或者直接使用SET GLOBAL命令把该变量的值设置为ON。预读本来是个好事儿如果预读到Buffer Pool中的页成功的被使用到那就可以极大的提高语句执行的效率。可是如果用不到呢这些预读的页都会放到LRU链表的头部但是如果此时Buffer Pool的容量不太大而且很多预读的页面都没有用到的话这就会导致处在LRU链表尾部的一些缓存页会很快的被淘汰掉也就是所谓的劣币驱逐良币会大大降低缓存命中率。
情况二有的小伙伴可能会写一些需要扫描全表的查询语句比如没有建立合适的索引或者压根儿没有WHERE子句的查询。
扫描全表意味着什么意味着将访问到该表所在的所有页
假设这个表中记录非常多的话那该表会占用特别多的页当需要访问这些页时会把它们统统都加载到Buffer Pool中
这也就意味着吧唧一下Buffer Pool中的所有页都被换了一次血其他查询语句在执行时又得执行一次从磁盘加载到Buffer Pool的操作。
而这种全表扫描的语句执行的频率也不高每次执行都要把Buffer Pool中的缓存页换一次血
这严重的影响到其他查询对 Buffer Pool的使用从而大大降低了缓存命中率。总结一下上面说的可能降低Buffer Pool的两种情况
加载到Buffer Pool中的页不一定被用到。如果非常多的使用频率偏低的页被同时加载到Buffer Pool时可能会把那些使用频率非常高的页从Buffer Pool中淘汰掉。
因为有这两种情况的存在所以设计InnoDB的大佬把这个LRU链表按照一定比例分成两截分别是
一部分存储使用频率非常高的缓存页所以这一部分链表也叫做热数据或者称young区域。另一部分存储使用频率不是很高的缓存页所以这一部分链表也叫做冷数据或者称old区域。
大家要特别注意一个事儿我们是按照某个比例将LRU链表分成两半的不是某些节点固定是young区域的某些节点固定是old区域的随着程序的运行某个节点所属的区域也可能发生变化。 那这个划分成两截的比例怎么确定呢对于InnoDB存储引擎来说我们可以通过查看系统变量innodb_old_blocks_pct的值来确定old区域在LRU链表中所占的比例
有了这个被划分成young和old区域的LRU链表之后设计InnoDB的大佬就可以针对我们上面提到的两种可能降低缓存命中率的情况进行优化了
针对预读的页面可能不进行后续访情况的优化 设计InnoDB的大佬规定当磁盘上的某个页面在初次加载到Buffer Pool中的某个缓存页时该缓存页对应的控制块会被放到old区域的头部。这样针对预读到Buffer Pool却不进行后续访问的页面就会被逐渐从old区域逐出而不会影响young区域中被使用比较频繁的缓存页。针对全表扫描时短时间内访问大量使用频率非常低的页面情况的优化 在进行全表扫描时虽然首次被加载到Buffer Pool的页被放到了old区域的头部但是后续会被马上访问到每次进行访问的时候又会把该页放到young区域的头部这样仍然会把那些使用频率比较高的页面给顶下去。 有同学会想可不可以在第一次访问该页面时不将其从old区域移动到young区域的头部后续访问时再将其移动到young区域的头部。回答是行不通因为设计InnoDB的大佬规定每次去页面中读取一条记录时都算是访问一次页面而一个页面中可能会包含很多条记录也就是说读取完某个页面的记录就相当于访问了这个页面好多次。 咋办全表扫描有一个特点那就是它的执行频率非常低谁也不会没事儿老在那写全表扫描的语句玩而且在执行全表扫描的过程中即使某个页面中有很多条记录也就是去多次访问这个页面所花费的时间也是非常少的。 所以我们只需要规定在对某个处在old区域的缓存页进行第一次访问时就在它对应的控制块中记录下来这个访问时间如果后续的访问时间与第一次访问的时间在某个时间间隔内那么该页面就不会被从old区域移动到young区域的头部否则将它移动到young区域的头部。上述的这个间隔时间是由系统变量 innodb_old_blocks_time 控制的
综上所述正是因为将LRU链表划分为 young 和 old 区域这两个部分又添加了 innodb_old_blocks_time 这个系统变量才使得预读机制和全表扫描造成的缓存命中率降低的问题得到了遏制因为用不到的预读页面以及全表扫描的页面都只会被放到old区域而不影响young区域中的缓存页。
更进一步优化LRU链表
LRU链表这就说完了么没有早着呢 对于young区域的缓存页来说我们每次访问一个缓存页就要把它移动到LRU链表的头部这样开销是不是太大啦毕竟在young区域的缓存页都是热点数据也就是可能被经常访问的这样频繁的对LRU链表进行节点移动操作是不是不太好啊 是的为了解决这个问题其实我们还可以提出一些优化策略比如只有被访问的缓存页位于young区域的1/4的后边才会被移动到LRU链表头部这样就可以降低调整LRU链表的频率从而提升性能也就是说如果某个缓存页对应的节点在young区域的1/4中再次访问该缓存页时也不会将其移动到LRU链表头部。
刷新脏页到磁盘
后台有专门的线程每隔一段时间负责把脏页刷新到磁盘这样可以不影响用户线程处理正常的请求。主要有两种刷新路径
从LRU链表的冷数据中刷新一部分页面到磁盘。
后台线程会定时从LRU链表尾部开始扫描一些页面扫描的页面数量可以通过系统变量innodb_lru_scan_depth来指定
如果从里边儿发现脏页会把它们刷新到磁盘。这种刷新页面的方式被称之为BUF_FLUSH_LRU。从flush链表中刷新一部分页面到磁盘。
后台线程也会定时从flush链表中刷新一部分页面到磁盘刷新的速率取决于当时系统是不是很繁忙。
这种刷新页面的方式被称之为BUF_FLUSH_LIST。有时候后台线程刷新脏页的进度比较慢导致用户线程在准备加载一个磁盘页到Buffer Pool时没有可用的缓存页这时就会尝试看看LRU链表尾部有没有可以直接释放掉的未修改页面如果没有的话会不得不将LRU链表尾部的一个脏页同步刷新到磁盘和磁盘交互是很慢的这会降低处理用户请求的速度。这种刷新单个页面到磁盘中的刷新方式被称之为 BUF_FLUSH_SINGLE_PAGE。
当然有时候系统特别繁忙时也可能出现用户线程批量的从flush链表中刷新脏页的情况很显然在处理用户请求过程中去刷新脏页是一种严重降低处理速度的行为毕竟磁盘的速度满的要死这属于一种迫不得已的情况不过这得放在后边介绍redo日志的checkpoint时说了。
多个Buffer Pool实例
我们上面说过Buffer Pool本质是InnoDB向操作系统申请的一块连续的内存空间在多线程环境下访问Buffer Pool中的各种链表都需要加锁处理什么的在Buffer Pool特别大而且多线程并发访问特别高的情况下单一的Buffer Pool可能会影响请求的处理速度。所以在Buffer Pool特别大的时候我们可以把它们拆分成若干个小的Buffer Pool每个Buffer Pool都称为一个实例它们都是独立的独立的去申请内存空间独立的管理各种链表独立的等等所以在多线程并发访问时并不会相互影响从而提高并发处理能力。我们可以在服务器启动的时候通过设置innodb_buffer_pool_instances的值来修改Buffer Pool实例的个数比方说这样
[server]
innodb_buffer_pool_instances 2
