首页 > 数据库 > mysql教程 > InnoDB存储引擎关键特性

InnoDB存储引擎关键特性

WBOY
发布: 2016-06-07 17:30:08
原创
1080 人浏览过

InnoDB存储引擎会监控对表上索引的查找,如果观察到建立哈希索引可以带来速度的提升,则建立哈希索引-gt;通过缓冲池的B+树构造,

1、插入缓冲Insert Buffer--给InnoDB存储引擎带来了性能
插入缓冲和数据页一样,是物理页的一个组成部分。
(1)主键primary key是行唯一的标识符,在应用程序中行记录的插入顺序是按照主键递增的顺序进行插入的->插入聚集索引一般是顺序的,不需要磁盘随机读取。
(2)非聚集的辅助索引secondary index不唯一,进行插入操作时,非聚集索引叶子结点的插入不是顺序的,折旧需要离散的访问非聚集索引页,插入性能低(B+树的特性决定了非聚集索引的离散性)
插入缓冲->对于非聚集索引的插入或更新操作,不是每一次直接插入,而是先判断插入的非聚集索引页是否在缓冲池中,在则直接插入;否则先放入一个插入缓冲区中,再以一定的频率执行插入缓冲和非聚集索引叶子结点的合并。
mysql> show engine innodb status;
...
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 7545, free list len 3790, seq size 11336,
8075308 inserts, 7540969 merged recs, 2246304 merges
...
7545已用,3790空闲,11336插入缓冲大小=7545+3790,8075308插入的记录数,7540969合并的页的数量,2246304合并的次数,7540969:2246304≈3:1
注:插入缓冲默认情况下最大可以占用1/2的缓冲池内存,可修改IBUF_POOL_SIZE_PER_MAX_SIZE进行控制。
插入缓冲使用的条件:
(1)索引是辅助索引;
(2)索引不是唯一的。
2、两次写Double Write--给InnoDB存储引擎带来数据的可靠性
部分失效partial page write:当数据库宕机时,数据库正在写一个页面且只写了一部分导致数据丢失->根本原因是mysql的page size跟系统文件的page size不一致,导致在写数据时,系统并不是把整个buffer pool page一次性写到disk上。(比如16K的页,只写了前4K)
重做日志redo log:记录的是对页的物理操作,如偏移量800,写'AAA'记录,即如果这个页本身已经损坏,再对其进行重做已经没有任何意义。
两次写double write:在应用apply重做日志前,我们需要一个页的副本,当写入失效发生时,先通过副本来还原该页,再进行重做,这就是double write。
恢复工作方式:如果是写doublewrite buffer本身失效,那么这些数据不会被写到磁盘,innodb此时会从磁盘载入原始数据,然后再通过log files计算出正确的数据,重新写入到doublewrite buffer;如果是写磁盘失败,则直接用buffer的数据再写一遍。
doublewrite架构如下图所示:

InnoDB存储引擎关键特性


doublewrite
内存中的doublewrite buffer,大小为2MB;
物理磁盘上共享表空间中连续的128页,大小为2MB(2MB=2*1MB=2*64*16KB=2*64页)。
过程描述
当缓冲池的脏页刷新时flush dirty page,并不直接写磁盘,而是会通过memcpy函数将脏页拷贝到内存中的doublewrite buffer,,之后通过doublewrite buffer分两次,每次写入1MB到共享表空间的物理磁盘上,然后马上调用fsync函数同步磁盘,避免缓冲写带来的问题。
->在这个过程中,因为doublewrite页是连续的,因此整个过程是顺序写的,开销并不是很大;在完成doublewrite页写入后,再将doublewrite buffer中的页写入到各个表空间文件中,此时的写则是离散的。
Innodb_dblwr_pages_written:Innodb_dblwr_writes≈64:1(一次可刷新64个脏页),而当系统写入压力并不是很高时,远小于64:1。
在master/slave主从复制结构中,master server需开启两次写功能;slave server应禁用两次写功能。
3、自适应哈希索引Adaptive Hash Index
哈希hash->非常快的查找方法O(1),常用于join操作(SQL Server和Oracle中的哈希连接)
设计思想:数据库自优化->InnoDB存储引擎会监控对表上索引的查找,如果观察到建立哈希索引可以带来速度的提升,则建立哈希索引->通过缓冲池的B+树构造,因此建立速度很快,且不需要将整个表都建立哈希索引,InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。其只能用来搜索等值的查询,如select * from table where index_col='xxx'。
启用自适应哈希索引后,读写速度可提高2倍,对辅助索引的连接操作性能可提高5倍。
mysql> show engine innodb status;
...
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 7545, free list len 3790, seq size 11336,
8075308 inserts, 7540969 merged recs, 2246304 merges
Hash table size 4980499, node heap has 1246 buffer(s)
1640.60 hash searches/s, 3709.46 non-hash searches/s
...
1640.60:3709.46≈1:2.26

参考:

linux

相关标签:
来源:php.cn
本站声明
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板