Areses

导航

INNODB引擎的4大特性

1、插入缓存
2、二次写
3、自适应哈希
4、预读
一、插入缓存(insert buffer)
插入缓冲(insert Buffer/Change Buffer):提升插入性能,change buffering是insert buffer的加强,Insert buffer只针对Insert有效,Change buffer对Insert、delete、update(delete+insert)、purge都有效
只对于非聚集索引(非唯一)的插入和更新有效,对于每一次的插入不是写到索引页中,而是先判断插入的非聚集索引页是否在缓冲池中,如果在则字节插入;若不在,则先放到insert Buffer中,在按照一定的效率进行合并操作,在写会Disk。这样通常能将多个插入合并到一个操作中,目的还是为了减少随机IO带来性能损耗。

使用插入缓冲的条件:

  1. 非聚集索引
  2. 非唯一索引

Change Buffer是作为Buffer pool中的一部分存在。Innodb_change_buffering参数缓存所对应的操作:(update会被认为是delete+insert)
Innodb_change_buffering:设置的值有:Insert、deletes、purges、changes(Inserts和deletes)、all(默认)、none。

all:默认值,缓存Insert,delete,purges操作。
Inserts:缓存Insert操作。
deletes:缓存deletes操作。
Changes:缓存Insert和delete操作。
purges:缓存后台之心的物理删除操作。

可以通过参数控制其使用的大小:
Innodb_change_buffer_max_size,默认是25%,即缓冲池的1/4,最大可设置为1/2。当MySql实例中有大量的修改操作时,要考虑怎大Innodb_change_buffer_max_size

在一定频率下进行合并,所谓的频率是什么条件?

  1. 辅助索引页被读取到缓存池中,正常的select先检查Insert Buffer是否有 该非聚集索引页的存在 ,若有则合并插入。
  2. 辅助索引页没有可用空间,空间小于1/32页的大小,则会强制合并操作。
  3. Master Thread每秒和每10秒的合并操作。

二、二次写(Double wite)
DoubleWrite缓存是位于系统表空间的存储区域,用来缓存Innodb的数据页从Innodb Buffer pool中flush之后并写入到数据文件之前,所以当操作系统或者数据库进程在数据页写磁盘的过程中崩溃,Innodb可以在DoubleWrite缓存中找到数据页的备份而用来执行Crash恢复。数据页写入到DoubleWrite缓存的动作所需要的的IO消耗,此写入操作会以一次大的连续块的方式写入

在应用(apply)重做日志前,用户需要一个页的副本,当写入失效发生时,先通过页的副本来还原该页没在进行重做,这就是Double Write

Double Write组成:

  1. 内存中的double write buffer大小2M
  2. 物理磁盘上共享表空间中连续的128个页,即2个区(extend),大小同样为2M
  3. 对缓冲池的脏页进行刷新时,不是直接写磁盘,而是会通过memcpy() 函数将脏页相纸到内存中的Double Write Buffer,之后通过Double Write再分两次,每次1M顺序地写入 共享表空间的物理磁盘上,在这个工程中,因为Double Write页是连续的,因此 这个过程是顺序写的,开销并不是很大。在完成Double Write页的写入后,再讲Double Write Buffer 中的页写入各个表空间文件中,此时的写入这是离散的。如果操作系统再将页写入磁盘的过程中发生了崩溃,在回复过程中,Innodb可以从共享表空间中的Double Write中找到该页的一个副本,将其复制到表空间文件,再应用重做日志。

image
三、自适应哈希索引(AHI)
Adaptive Hash index属性使得Innodb更像是内存数据库,该属性通过Innodb_adaptive_hash_index开启,也可以通过——skip-innodb_adaptive_hash_index参数关闭。
注:可以关闭自适应Hash
生成Hash索引的条件比较苛刻

  1. 索引是否被 访问了17次
  2. 索引中的某个页已经被访问了100次
  3. 访问模式必须是一样的。
    例如对于(a、p)访问模式情况:
    where a = xxx
    where a = xxx and b = xxx

Innodb存储引擎会监控对表上二级索引的查找,如果发现某二级索引被频繁访问 ,二级索引成为 热数据,建立哈希索引可以代理速度的提升。
经常访问的二级索引数据会自动被生成到hash索引里面去(最近连续被访问三次的数据),自适应哈希索引通过缓冲池的B+树构造而来,因此建立的速度很快。
哈希(Hash)是一种非常快的等值查找方法,一般情况下这种查找的时间复杂度为O(1) 即一般仅需要一次查找就能定位数据,而B+树的查找次数,取决于B+树的高度,在生产环境中,B+树的高度一般是3、4层,故需要3-4次的查询。

Innodb会监控对表上个索引页的查询,如果观察到简历哈希索引可以带来速度提升,则自动建立哈希索引,称之为自适应哈希索引(Adaptive Hash Index,AHI)

特点:

  1. 无序,没有树高
  2. 降低对二级索引树的频繁访问资源,索引树高<=4 访问索引:访问树,根节点,叶子节点。
  3. 自适应
    缺陷:
  4. jash自适应索引会占用Innodb buffer pool
  5. 自适应hash索引只适合搜索等值的查询,如select * from table where index_col='xxx' 而对于其他查找类型,如范围查找,是不能使用的。
  6. 极端情况下,自适应hash索引才有比较大的意义,可以减低逻辑读。

四、预读
Innodb使用两种预读算法来提高I/O性能:线性预读(linear read_ahead)和随机预读(randomread-ahead)为了区分这两种预读的方式,我们可以吧线性预读放到以extent为单位,而随机读放到exent中的page为单位,线性预读着眼于降下一个extent提前读取到 buffer pool中,而随机预读着眼于extent中的剩余的page提前读取到buffer pool中。

image

原文为:https://www.cnblogs.com/zhs0/p/10528520.html

posted on 2021-11-25 18:09  xxxsyzq  阅读(274)  评论(0编辑  收藏  举报