MySQL-Innodb-内存结构

一、 Innodb内存结构的基本组成1.1 基本结构说明Innodb内存结构的组成大致有Buffer pool缓冲池用于存储数据页、索引页包括自适应哈希索引、undolog缓冲区Change buffer变更缓冲区存在于buffer pool中Log buffer日志缓冲区1.2 为什么要有内存结构?如果所有数据操作例如增删查改统一都要与磁盘进行交互那么innodb存储引擎处理数据的性能就会大大降低。因为磁盘IO速度会比内存IO速度要慢很多很多现代应用开发大多数原则Innodb的原因就是因为Innodb可以通过内存、以及其他方式比如日志记录确保不丢失事务一致性的情况下提升性能1.3 Buffer pool 的结构1.3.1 大致结构Innodb中磁盘和内存的数据最小管理单位是页。Buffer pool中组织和管理页包括数据页、索引页方式如图一个MySQL服务器中可以有多个instances实例每个实例都可以独立进行DML操作。instances下管理多个Chunk每个Chunk都被分配一块连续的物理内存。这块物理内存中就存放了被缓存的Page。MySQL中支持通过innodb_buffer_pool_chunk_size、innodb_buffer_pool_instances、innodb_buffer_pool_size来配置内存大小但是不支持直接配置chunk的数量。我们可以通过(pool_size/instances)/chunk_size来计算每个chunk的大小1.3.2 page的组织方式在Innodb中页与页的组织方式是通过控制块来实现的控制块其实就相当于节点节点与节点之前相互连接形成逻辑上的链表。每个instance下都会单独维护这种结构的链表Free List 、Dirty List 、Clean List 后面会讲到。也就是说同一个instance下chunk与chunk管理的page都组织在同一套逻辑链表下。由于unlog 日志的组织方式也是页结构所以把undo log放到了buffer pool中通过控制块进行管理1.3.3 page和chunk的初始化方式每个chunk都有一块连续的内存。控制块会从左到右进行初始化而缓冲页则会从右到左进行初始化。如果中间不足以容纳一个控制块缓冲页那么这块内存会变成碎片区无法被使用。1.3.4 chunk的作用是什么每个chunk都会分配一块连续的物理内存。MySQL中内存大小调整的最小单位是chunk。如果要进行扩容像操作系统申请额外的chunk并初始化然后过载到Free List如果要缩容把空闲没有被使用的chunk归还给操作系统1.3.5为什么要区分多个实例之前讲到每一个instance可以独立的完成数据的DML操作这里的主要作用就是降低单一缓冲池全局锁的争抢提升MySQL的并发性能每个instance都维护独立的Free List 、Dirty List 、Clean Listinnodb把数据操作请求根据表空间id和页id分配给对应的instance完成DML操作不同instance的数据相互不会干扰因为Innodb保证buffer pool中每个缓冲页都是唯一的1.3.6 Buffer pool的缓存淘汰策略1.3.6.1 缓存结构Buffer pool中每个实例都会维护三个链表以此来保证缓存淘汰Free List保存已经从Flush List写回磁盘已经被用过的缓冲页Lru List此链表实际参与buffer pool的缓存淘汰记录了脏页和干净页当有新的缓存页时从Free List中获取FLush ListLru List中所有脏页在这里都会有对应副本当脏页写回磁盘后会把空闲页重新叫给Free List1.3.6.2 缓存淘汰实现原理Lru List参与缓存淘汰Free List和Flush List用于辅助。Lru List不是标准的Lru缓存结构它的具体实现方式如图相比于传统LruMySQL中Lru缓存链表在中间开了个口。左侧约5/8是young区右侧3/8是old区。当有新数据插入时将新数据插入中间。以用数据页被访问的缓存淘汰策略当访问的页在Lru list中如果在yong区直接移动到yong头。如果在old区实际上Innodb会记录每个old区中每个页在Old区停留的时间默认1000ms。大于这个值移动到yong头否则只移动到old头。1.3.6. 3 为什么要把Lru缓存一分为二如果用传统Lru当MySQL涉及临时的全表操作时原先已经缓存过的热数据可能会被全部刷走。操作完成后Lru链表中全是冷数据需要重新热更新这种场景下传统Lru就不适合使用了。1.4 ChangeBuffer1.4.1 changeBuffer作用change buffer的主要作用是针对修改非唯一二级索引进行的。这里先讲一个前置知识磁盘操作中随机IO要比顺序写慢得多实际上不论是二级索引还是聚集索引随机的数据操作都会导致磁盘的随机IO原因很简单Innodb中是通过B树来管理数据的而树型结构的数据本身在物理层面就是随机分布的。所以索引操作不可避免会产生随机IO而change buffer的作用就是尽可能的减少二级索引的随机IO次数从而提升MySQL性能1.4.2 changeBuffer怎么减少二级索引随机IO的Change Buffer 的核心思想是**“攒批异步合并写入”**其工作机制分为三步缓存修改异步延迟当对非唯一二级索引执行插入、更新或删除操作时InnoDB 不会立即将受影响的索引页从磁盘读取到内存而是将这次修改操作如“在页号X插入主键IDY”记录到 Change Buffer 中。这一步完全跳过了修改前的“随机读”IO。触发合并读入即合当后续某个查询需要读取该二级索引页或者后台线程主动刷盘时InnoDB 才将该索引页从磁盘加载到 Buffer Pool。应用变更批量落盘将 Change Buffer 中针对该索引页积压的所有修改操作**一次性合并Merge**到刚加载的内存数据页上随后将该干净页异步刷回磁盘。通过这种机制Change Buffer 充分利用了计算机系统中的两个重要特性时间局部性的应用合并重复操作如果某一行数据在短时间内被反复修改例如同一行1秒内被Update了100次没有Change Buffer时就要产生100次随机IO有了它这100次修改在内存中合并成1次最终结果最终只触发1次磁盘写入消除了时间维度上的重复IO。空间局部性的应用批量处理同页如果修改操作分散在同一个索引页物理上连续的16KB空间内的不同行记录上Change Buffer 会将这些散落的修改积攒起来。等到该页被加载时所有修改被一次性批量应用并写入磁盘将原本可能需要多次的随机IO缩减为单次IO写入一个完整的连续数据页。1.2.2 聚集索引/非唯一二级索引为什么不能用change buffer聚集索引/非唯一二级索引都要求同一个表中值必须唯一唯一性校验不能是异步的。例如同时插入两个值每个值的唯一索引都是1。那么后边合并数据的时候就乱套了。1.5 AHI1.5.1 概述AHI也就是自适应哈希同样保存在Buffer pool中但是只占buffer pool的很少容量。AHI的key存储的二级制值由对应行数据的主键和二级索引计算而来AHI的valude存储的是对应所在的缓冲页的内存地址以及偏移量这样就可以快速对应行数据。1.5.2 作用AHI可以在不牺牲事务一致性的情况下把高频查询数据以键值对的形式存储在哈希表内存中以提升查询性能。1.5.3 为什么要引入AHIbuffer pool中虽然有 page table的类似哈希表的结构可以根据表空间id和页id快速定位页但是它不能快速查询具体的某个行数据。也就是说AHI是针对某个频发查询数据行的操作进行优化。1.6 page hash和AHI区别page hash是每一个buffer pool中每一个instance都会维护的hash表数据它能根据要查询的数据的表空间id数据页id快速定位它所在的数据页。特性Page Hash自适应哈希索引 (AHI)核心目的快速定位数据页判断一个磁盘数据页是否已在 Buffer Pool 中。快速定位数据行加速对热点索引值的等值查询跳过 B 树的遍历。Key (键)(space_id, page_no)即“表空间ID 数据页号”。索引键值 (或前缀)由查询条件中的索引列值构成。Value (值)缓存页的地址 / 控制块指针指向 Buffer Pool 中对应的数据页。数据行在 B 树叶子节点中的位置或直接指向叶子节点中的记录。所有者每个 Buffer Pool Instance 独立维护一份。全局维护但内部可分区以减少竞争。二、LogBuffer2.1 作用用于存储redo log。redo log 重做日志用于记录对应操作要修改的行、字段、值。redo log的作用就是确保灾难恢复和事务的一致性。2.2 工作流程redolog会以事务为单位把更新操作保存到log buffer然后根据不同策略写入磁盘由innodb_flush_log_at_trx_commit控制1实时写每写入一个事务到内存就刷盘一次Innodb默认0每秒写每秒把已保存的修改操作刷盘2根据操作系统调度这种方式不确定性大不论何种方式刷盘的方式都是调用操作系统的write()接口写入操作系统chache page只是异步调用fsync()时机不同实时写则是每个事务写入后直接fsync()落盘。