MySQL中的存储引擎(INNODB)

innodb和myisam区别

  1. innodb支持事务, myisam不支持事务
  2. innodb支持行级锁, myisam支持表锁
  3. innodb支持外键, myisam不支持
  4. innodb不支持全文检索,myisam支持
  5. innodb支持mvcc(Multiversion Concurrency Control 间隙锁), myisam不支持

聚簇索引和非聚簇索引

1.聚集索引

聚集索引是按每张表的主键构造的一颗B+树,并且叶节点中存放着整张表的行记录数据,因此也让聚集索引的节点成为数据页,这个特性决定了索引组织表中数据也是索引的一部分。由于实际的数据页只能按照一颗B+树进行排序,所以每张表只能拥有一个聚集索引。查询优化器非常倾向于采用聚集索引,因为其直接存储行数据,所以主键的排序查询和范围查找速度非常快。

不是物理上的连续,而是逻辑上的,不过在刚开始时数据是顺序插入的所以是物理上的连续,随着数据增删,物理上不再连续。

2.辅助索引

辅助索引页级别不包含行的全部数据。叶节点除了包含键值以外,每个叶级别中的索引行中还包含了一个书签,该书签用来告诉InnoDB哪里可以找到与索引相对应的行数据。其中存的就是聚集索引的键。

辅助索引的存在并不影响数据在聚集索引的结构组织。InnoDB会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键,然后通过主键索引找到一个完整的行记录。当然如果只是需要辅助索引的值和主键索引的值,那么只需要查找辅助索引就可以查询出索要的数据,就不用再去查主键索引了。

innodb的关键特性

innodb的关键特性包括:插去缓冲, 两次写, 自适应哈希索引

插入缓冲

主键是行唯一的标识符,在应用程序中行记录的插入顺序是按照主键递增的顺序进行插入的,因此,插入聚集索引一般是顺序的,不需要磁盘的随机读取。

聚集索引(聚簇索引):聚集索引是指数据库表行中数据的物理顺序与键值的逻辑(索引)顺序相同
Innodb存储开创地设计了插入缓冲,对于非聚集索引的插入或更新插入,不是每一次直接插入索引页,而是先判断插入的非聚集索引页是否在缓冲池。如果在,则直接插入;如果不在,则先放入一个插入缓冲区中,好似欺骗数据库这个非聚集的索引已经查到叶子节点上,然后再以一定的频率执行插入缓冲和非聚集索引页子节点的合并操作,这时通常能将多个插入合并到一个操作中,这就大大提高了对聚集索引执行插入和修改操作的性能。
插入缓冲的两个条件:
索引是辅助索引:索引不是唯一的

两次写

当数据库死机时, 可能发生数据库正在写一个页面,而这个页只写来了一部分, 我们称之为部分写失效。有人想如果发生写失效,可以重做日志进行恢复。这是一个办法的但必须清楚,重做日志分析记录的是对页的物理操作,如果这个页本身已经损坏,在对其重做也没意义。当写入部分失效时,先通过页的副本来还原该页,再进行重做,这就是doublewrite

Doublewrite由两部分组成:一部分是内存池中的饿doublewrite buffer,另一部分是物理磁盘上的共享表空间中的连续的128个页,即两个区。当缓冲页的脏页刷新时,并不直接写磁盘,而是会通过memcpy函数将脏页先拷贝到内存中的doubleewrite buffer .之后通过doublewrite buffer再分两次,每次写入 1MB到共享表空间的物理磁盘上,然后马上调用fsync函数,同步磁盘,避免缓冲带来的问题。

自适应哈希引擎

哈希是一种非常快的查找方法,一般情况下查找时间的复杂度为O(1),常用于连接操作
Innodb存储引擎会监控对表上索引的查找,如果观察到建立哈希索引可以带来速度的提升,则建立哈希索引,所以称之为自适应的。自适应哈希索引通过缓冲池中的B++树构造而来,因此j建立的速度会很快。而且不需要将整个表都建立哈希索引,INNODB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。

innodb支持的四种事务隔离级别

Read Uncommitted(读取未提交内容)

在该隔离级别,所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用,因为它的性能也不比其他级别好多少。读取未提交的数据,也被称之为脏读(Dirty Read)。

Read Committed(读取提交内容)

这是大多数数据库系统的默认隔离级别(但不是MySQL默认的)。它满足了隔离的简单定义:一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读(Nonrepeatable Read),因为同一事务的其他实例在该实例处理其间可能会有新的commit,所以同一select可能返回不同结果。

Repeatable Read(可重读)

这是MySQL的默认事务隔离级别,它确保同一事务的多个实例在并发读取数据时,会看到同样的数据行。不过理论上,这会导致另一个棘手的问题:幻读(Phantom Read)。简单的说,幻读指当用户读取某一范围的数据行时,另一个事务又在该范围内插入了新行,当用户再读取该范围的数据行时,会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制(MVCC,Multiversion Concurrency Control 间隙锁)机制解决了该问题。注:其实多版本只是解决不可重复读问题,而加上间隙锁(也就是它这里所谓的并发控制)才解决了幻读问题。

Serializable(可串行化)

这是最高的隔离级别,它通过强制事务排序,使之不可能相互冲突,从而解决幻读问题。简言之,它是在每个读的数据行上加上共享锁。在这个级别,可能导致大量的超时现象和锁竞争。

阅读更多
文章标签: innodb
上一篇MongoDB进阶
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭