当前位置：首页 > news >正文

网站即将上线页面代码网站模板源码下载网

news 2026/4/27 14:44:25

网站即将上线页面代码,网站模板源码下载网,服装网站模板,怎样可以提升自己的网站目录 InnoDB内存结构主要组成缓冲池缓冲池的作用缓冲池的结构缓冲池中页与页之间连接方式分析缓冲池如何组织数据控制块初始化页面初始化缓冲池中页的管理缓冲区淘汰策略查看缓冲池信息总结变更缓冲区-Chang Buffer 变更缓冲区的作用主要配置选项…目录 InnoDB内存结构主要组成缓冲池缓冲池的作用缓冲池的结构缓冲池中页与页之间连接方式分析缓冲池如何组织数据控制块初始化页面初始化缓冲池中页的管理缓冲区淘汰策略查看缓冲池信息总结变更缓冲区-Chang Buffer 变更缓冲区的作用主要配置选项查看当前变更缓冲区信息自适应哈希自适应哈希作用自适应哈希的配置查看自适应哈希信息日志缓冲区日志缓冲区的作用日志缓冲区写入磁盘与内存比较 InnoDB内存结构总结编辑 InnoDB内存结构主要组成内存结构主要构成 Buffer Pool缓冲区Change Buffer变更缓冲区adaptive_hash_index自适应哈希索引Log Buffer 日志缓冲区缓冲池缓冲池的作用缓冲池谓语InnoDB内存区域主要用于缓存表和索引的常用数据。通过将频繁访问的数据例如数据页、索引页保存到内存中缓冲池减少了磁盘的I/O操作从而提高数据库性能。缓冲池的结构 InnoDB的缓冲池至少包含一个Instance实例其中一个Instance是真正的缓冲池事例对象内存操作都是在Instance实例中进行每个Instance实例中都有一个Chunk服务器运行状态下动态调整块的大小然后没Chunk块有包含若干个从磁盘上加载到内存的page数据页缓冲池中页与页之间连接方式分析链接机制数据页在内存中的链接并未直接使用物理地址而是通过链表中的指针和偏移量来表示每个数据页头信息中包含一个next_record字段该字段记录了下一行数据的偏移量根据偏移量可以找到下一条数据数据页的逻辑连接数据页通过B树索引逻辑连接叶子节点为实际数据页非叶子节点存储指向子节点的指针双向链表所有控制块都是通过双向链表连接形成缓冲池LRU链表头结点最近访问的数据页尾结点最少访问的数据页优先淘汰链表节点的功能数据是否为脏页数据页的访问次数数据页的最后访问时间缓冲池如何组织数据加载数据页从磁盘中加载数据到缓冲池为每一个加载的数据页分配一个控制块控制块记录数据页的指针并插入到LRU链表的头部访问数据页通过控制块找到目标数据页更新控制块的访问信息将其移动到 LRU 链表头部淘汰数据页当缓冲池空间不足时从 LRU 链表尾部开始淘汰数据页如果是脏页先写回磁盘再释放内存中的数据页和磁盘上的数据页的关系磁盘中的数据页加载到内存后缓冲区有一个内存页与之对应内存中是使用控制块对其进行管理控制块中是有一个指针指向了内存中真实的数据页设置缓冲区大小通过系统变量Innodb_buffer_pool_size进行设置默认是128MB 缓冲池中instance数量 SHOW VARIABLES LIKE innodb_buffer_pool_instances;设置全局配置或配置文件中配置 //全局配置 SET GLOBAL innodb_buffer_pool_instances 数量;//配置文件 [mysqld] innodb_buffer_pool_instances 数量根据缓冲区大小进行设置如果缓冲区小于1GB那么自动设置为1如果缓冲区大于1GB那么默认值是8。最大的实例数量是64 chunk的作用 chunk是缓冲池中最小的分配管理单位每个chunk都有若干个页组成页是最小的数据存储单位。一个chunk一般是1MB一个数据页是16KB那么一个chunk中有64页 chunk的核心作用支持缓存池大小动态调整提升缓存池的内存管理效率减少大规模内存分配和锁竞争控制块初始化控制块在缓冲池初始化时与页面一起分配每个页面分配一个对应的控制块控制块的数量等于缓冲池中页面的数量控制块是使用双向链表组织开始缓冲池分配控制块数组初始化每个控制块的结构体将默认值填充到各个字段然后建立双向链表初始化链表的头尾指针 struct ControlBlock {void* page_ptr; // 指向页面的指针bool is_dirty; // 脏页标志int access_count; // 访问计数uint64_t timestamp; // 最后访问时间戳ControlBlock* prev; // 指向前一个控制块ControlBlock* next; // 指向后一个控制块 }; 页面初始化分配缓冲池实例的内存区域。将内存区域按照 16KB 切分成若干页面。初始化每个页面的头部元信息如页面类型、下一页偏移。将页面与控制块建立一一对应关系。内存先进行初始化然后建立控制块与内存中缓存数据页之间的关系从左边开始第一个控制块指向第一个缓冲数据页的内存地址控制块与页面的关系每个控制块通过指针指向缓冲池中的一个页面控制块和页面的数量相等每个控制块管理一个页面首先分配页面内存后记录页面的地址然后将页面地址存储到对应的控制块中最后将控制块加入到双向链表中配置缓冲池提升性能配置缓冲池大小配置多个缓冲池实例防止缓冲区扫描配置缓冲区预读取配置缓冲区的刷新策略保存和恢复缓冲池的状态缓冲池中页的管理分析页的三种状态 Free空闲页含义没有使用过的页可以用来存储新的数据这些页不包含任何有效的数据完全空闲作用当需要加载新的数据页到缓冲池中的时候InnoDB会优先从Free List中获取空闲页Clean干净页含义已经使用但是没有被修改的页与磁盘中的页内容一致所以是不需要写回磁盘作用clean页通通常都是存储在LRU最近最少使用列表中用于提供快速访问Dirty脏页含义已经被修改但是还没有写回磁盘的页这些页的内容与磁盘中的数据不同需要在某些条件下写回磁盘从而确保数据的持久性作用Dirty页一般被放在Flush List中等待后台线程触发特定条件后将其刷新到磁盘中三个链表管理页 Free List 管理所有的空闲页管理当需要加载新的数据时候从Free List中分配页如果Free List中没有空闲页会通过替换策略从LRU List中淘汰页动态变化LRU List 中淘汰的页被释放后会重新加入到Free ListLRU List 管理Clean 和 Dirty 页管理思路页的访问会更新其在LRU列表中的位置频繁访问的页会移动到列表前部最少使用的页会逐渐移动到尾部缓冲区需要更多空间的时候LRU列表尾部的页会被释放或者写回磁盘优化策略使用中点插入策略将新加载的也插入的LRU列表的中部避免新页短时间占用较高优先级下文详细分析Flush List 专门管理Dirty页管理当一个页被修改的时候会被标记为Dirty然后加入到Flush List中后台线程或者触发条件例如缓冲池不足就会定期扫描Flush List并将脏页写回到磁盘上动态变化当Dirty页被刷新到磁盘后会从Flush List中移除分析页管理中三种操作读操作加载数据页首先检查需要的页是否在缓冲池中如果命中缓存那么从缓冲池中读取如果没有命中缓存则从磁盘加载页到缓冲池从Free List分配空闲页或者从LRU List替换最少使用的页写操作修改数据页修改缓冲池中数据页后该页被标记为Dirty然后将脏页加入到Flush List中等待后续刷新磁盘替换页缓冲区不足的时候从LRU List 尾部选择使用最少的页如果是脏页那么先写回磁盘再释放释放后的页加入到Free List重新分配总结每个缓冲池通过三个列表管理三种内存页。Free未使用的页、Clean干净页、Dirty脏页拓展1内存如何快速找到目标页 InnoDB使用page Hash方式当磁盘数据加载到内存的时候用数据页的表空间ID和页号作为Key页在内存的地址为Value保存起来每次查询的时候通过Key快速定位到目标页如果内存中没有目标页则从磁盘中获取缓冲区淘汰策略分析 LRU机制分析页访问如果该页已在缓冲池中InnoDB 会将其移动到 LRU 列表的头部标记为最近使用。如果该页不在缓冲池中InnoDB 会从磁盘加载该页到缓冲池并插入到 LRU 列表中。页插入新加载的页并不会直接插入到 LRU 列表的头部而是通过中点插入策略页淘汰如果待淘汰页是 Clean 页则直接从 LRU 列表移除。如果是 Dirty 页则需先将其写回磁盘然后再移除。总结淘汰策略采用LRU 拓展1页的插入为什么在中部而不是新列表的头部如果直接将新页插入到列表的头部容易受到顺序扫描或者批量数据加载的影响从而会导致缓冲池被新加载的数据被污染频繁访问的页反而会被淘汰所以使用中点插入解决该问题 InnoDB在读取页的时候会有预读也就是根据当前访问记录自动推断后面可能访问哪些页然后一起加载到内存从而提高查询效率从中间点插入可以让其尽快淘汰查看缓冲池信息 SHOW ENGINE INNODB STATUS\G; Buffer pool size缓冲池的总大小以页为单位。Free buffers空闲页的数量。Database pages已加载到缓冲池的数据库页数量。Modified db pages脏页已被修改但尚未写回磁盘的页数量。Pages read自服务器启动以来从磁盘读取的页数。Pages written自服务器启动以来写入磁盘的页数。Pages created自服务器启动以来新创建的页数。Read requests逻辑读请求的总数。Write requests写请求的总数。总结缓冲池的主要作用是用于缓存各种数据最主要的就是缓存从磁盘中加载数据页从而提高读取效率缓冲池为方便数据组织定义了不同的数据结构Buffer Pool中包含至少一个InstanceInstance包含至少一个ChunkChunk管理若干个个从磁盘中加载到内存的Page页缓冲池使用三种链表管理三种内存页分别是Free List 、LRU List和FLush List淘汰策略是LRU算法变更缓冲区-Chang Buffer 变更缓冲区的作用分析变更缓冲区存储内容用于缓存次级索引页的膝盖内容例如INSERT\UPDATA\DELETE如果修改涉及的次索引页还没有被加载到缓冲池中那么变更缓冲池就会临时保存这些修改而不是立刻就加载索引页到缓冲池中并写入磁盘写入磁盘触发条件当涉及的索引页不在缓冲池中的时候变更缓冲区会暂时存储修改操当后面其他操作需要访问这些索引页的时候InnoDB会将索引页从磁盘加载到缓冲池中并将变更缓冲区的修改合并到加载页中总结减少磁盘I/O次级索引修改频繁的时候变更缓冲区避免了每次修改都触发磁盘读取操作批量合并修改后再写入磁盘有效减少随机磁盘访问提高读写性能通过合并操作减少了磁盘的随机写入次数优化了磁盘写入性能对于不经常访问的索引页变更缓冲区延迟了其加载时间降低了缓冲池的压力拓展主键索引和二级索引主键索引就像一本书的目录唯一且直接指向内存二级索引就像术后的关键词索引表可以针对于多列进行加速查询但是需要回表找到数据行二级索引不是唯一的针对的是非主键列允许多个数据行有相同值二级索引的存在让查询更加灵活高效主要配置选项分析缓冲类型控制变更缓冲区的行为指定变更缓冲区缓存哪些类型 all缓存所有次级索引的修改操作默认值insert进缓存次级层插入操作deletes次级的删除操作changes缓存插入和删除操作purges仅缓存清除操作none禁用变更缓冲区 // 动态调整 SET GLOBAL innodb_change_buffering inserts;// 修改配置文件[mysqld] innodb_change_buffering inserts变更缓冲池大小范围1-50表示占缓冲池大小的百分比 // 动态调整 SET GLOBAL innodb_change_buffer_max_size 30; -- 设置为 30%//配置文件 [mysqld] innodb_change_buffer_max_size 30总结主要配置项就是缓冲类型和更改缓冲区的最大大小查看当前变更缓冲区信息 SHOW ENGINE INNODB STATAUS\G//命令同上找到对应的信息即可自适应哈希自适应哈希作用分析工作原理分析 InnoDB动态监控缓冲池页的访问情况如果某些表或者索引页被频繁访问并且通过创建哈希表可以显著提升查询性能InnoDB会自动为其生成哈希索引构建哈希索引自适应哈希索引是基于B树索引动态生成其将频繁访问的页或行的索引转化为哈希表的条目映射到内存的位置自适应哈希索引存储在内存中全部依赖缓冲池空间启动和关闭命令 SET GLOBAL innodb_adaptive_hash_index 1;SET GLOBAL innodb_adaptive_hash_index 0;总结自适应哈希可以提升查询速度通过减少索引层次的遍历显著提升查询效率同时基于缓冲池的构建直接利用已有的数据和索引页拓展使用自适应哈希的原因提升查询性能B树已经非常高效但是其需要多层遍历自适应哈希索引通过直接映射的方式减少查询路径上的层次减少系统资源消耗针对于高频访问的路径B树多次比较和遍历会大量消耗CPU资源自适应哈希通过避免遍历和比较降低CPU资源的利用简化高频查询针对于某些频繁重复查询的模式自适应哈希索引可以显著减少查询时间拓展自适应哈希KV设置 Key来源自适应哈希Key是查询条件的索引键值Value则是该Key对应缓冲池中的B树页的内存地址。自适应哈希索引通过将Key映射到该Value可以直接跳转到缓冲池中的内存位置避免了遍历B树的操作映射过程分析当某一个索引键频繁的被访问自适应哈希索引会记录该Key和Value的关系查询的时候直接通过哈希值找到对应的Value无需要再去访问B树的多级结构拓展自适应哈希索引存储位置自适应哈希是存储在缓冲池中的内存区域中缓冲池初始化后分配一部分空间用于存储自适应哈希为了避免高并发访问自适应哈希引起锁的竞争InnoDB支持对哈希索引进行分区该分区机制可以显著减少多线程访问自适应哈希索引时的冲突自我理解例如在图书馆找一本书的场景为被背景。传统B树索引则每次读者找书都逐层开始招数即使手里有目录但还是需要一页一页的查找自适应哈希则是将那些热门书籍放在缓冲区的快速取书区中所以此时找书的时候就不需要去按照目录逐层寻找。高并发场景下就会出现问题因为设置快速取书区只有一张桌子当多个人去找不同的热门书籍的时候这些人就会排队所以也就导致了锁竞争分区解决该问题的思路图书馆中设置多个桌子根据热门数据的类型将其放在不同的桌子那么当读者来找书的时候找到不同的桌子然后在自己的分区中上锁这样就提高了效率技术角度理解自适应哈希的分区机制也就是把一个大的快速指引区域一个单个哈希表拆分成多个小的指引区域通过哈希函数计算将不同查询条件Key分配到不同区这样做的好处就在于当多个线程访问的时候如果其查询的数据分配到了不同的分区也是可以同时工作的不会相互阻塞。自适应哈希的配置启用和禁用 // 临时关闭和启用SET GLOBAL innodb_adaptive_hash_index OFF; -- 禁用 SET GLOBAL innodb_adaptive_hash_index ON; -- 启用// 配置文件[mysqld] innodb_adaptive_hash_index 0 # 禁用分区数量配置通过调整哈希索引分区数量从而减少高并发访问时的锁竞争每个分区都有一个独立的哈希表线程访问的时候只需要锁定对应分区即可不需要整个哈希表 SET GLOBAL innodb_adaptive_hash_index_parts 16; -- 设置为 16 个分区// 配置文件[mysqld] innodb_adaptive_hash_index_parts 16缓冲池大小设置 SET GLOBAL innodb_buffer_pool_size 8G; -- 设置缓冲池为 8GB查看自适应哈希信息查看自适应哈希的状态 Hash table size哈希表大小。Used cells已使用的哈希表条目。Total searches 和 Successful searches表示查询命中率越接近 100%AHI 的效果越好查询性能统计命中率计算日志缓冲区日志缓冲区的作用总结缓存事务日志在事务执行过程中InnoDB 会将所有需要写入到 Redo Log 的信息先写入日志缓冲区这些信息包括事务对表数据的修改用于在数据库崩溃时进行恢复提高写入效率直接将每次事务的日志写入磁盘会产生大量的随机 I/O 操作影响性能日志缓冲区通过将多个事务的日志批量写入磁盘显著减少磁盘写入次数从而提高性能事务持久性 Redo Log 是 InnoDB 支持事务持久性的核心组件。即使数据库崩溃也可以通过 Redo Log 恢复已提交的事务日志缓冲区确保在事务提交时相关日志已经持久化到磁盘崩溃恢复当 MySQL 服务意外中断或崩溃时日志缓冲区中的数据如果已经被刷新到磁盘的 Redo Log 文件InnoDB 可以利用这些日志恢复数据日志缓冲区写入磁盘与内存比较日志缓冲区工作流程分析当事务修改表中数据的时候InnoDB会先修改操作记录未日志条目然后写入日志缓冲区日志缓冲区中的日志会定期或者在事务提交的时候刷新到磁盘中刷新的时间则是由参数innodb_flush_log_at_trx_commit决定当日志从缓冲区刷新到磁盘后事务的修改才被认为是持久化日志通过缓冲区写入的原因分析根本原因就是尽量减少磁盘I/O先写入到缓冲区中然后统一刷新到磁盘中这样就实现了一次磁盘I/O写入多条日志从而提高效率 InnoDB内存结构总结

查看全文

http://www.hkea.cn/news/14436101/