luxuze.github.io

github pages

View on GitHub

MySQL 中常用存储引擎

存储引擎

  1. 存储引擎其实就是对于数据库文件的一种存取机制,如何实现存储数据,如何为存储的数据建立索引以及如何更新,查询数据等技术实现的方法。
  2. MySQL 中的数据用各种不同的技术存储在文件(或内存)中,这些技术中的每一种技术都使用不同的存储机制,索引技巧,锁定水平并且最终提供广泛的不同功能和能力。在 MySQL 中将这些不同的技术及配套的相关功能称为存储引擎。

innoDB

  1. 提供了事务,回滚以及系统崩溃修复能力和多版本迸发控制的事务的安全。

  2. 支持自增长列(auto_increment),自增长列的值不能为空,如果在使用的时候为空的话怎会进行自动存现有的值开始增值,如果有但是比现在的还大,则就保存这个值。

  3. 支持外键(foreign key) ,外键所在的表称为子表而所依赖的表称为父表。

  4. 支持事务,以及事务相关联功能。

  5. 支持 mvcc 的行级锁。

  6. 索引使用的是 B+Tree

MyISAM

  1. 设计简单,数据以紧密格式存储。对于只读数据,或者表比较小、可以容忍修复操作,则依然可以使用它。
  2. 提供了大量的特性,包括压缩表、空间数据索引等。
  3. 不支持事务。
  4. 不支持行级锁,只能对整张表加锁,读取时会对需要读到的所有表加共享锁,写入时则对表加排它锁。但在表有读取操作的同时,也可以往表中插入新的记录,这被称为并发插入(CONCURRENT INSERT)。
  5. 可以手工或者自动执行检查和修复操作,但是和事务恢复以及崩溃恢复不同,可能导致一些数据丢失,而且修复操作是非常慢的。
  6. 如果指定了 DELAY_KEY_WRITE 选项,在每次修改执行完成时,不会立即将修改的索引数据写入磁盘,而是会写到内存中的键缓冲区,只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入磁盘。这种方式可以极大的提升写入性能,但是在数据库或者主机崩溃时会造成索引损坏,需要执行修复操作。
  7. MyISAM 类型的表支持三种不同的存储结构:静态型、动态型、压缩型。

    • 静态型:指定义的表列的大小是固定(即不含有:xblob、xtext、varchar 等长度可变的数据类型),这样 MySQL 就会自动使用静态 MyISAM 格式。使用静态格式的表的性能比较高,因为在维护和访问以预定格式存储数据时需要的开销很低;但这种高性能是以空间为代价换来的,因为在定义的时候是固定的,所以不管列中的值有多大,都会以最大值为准,占据了整个空间。
    • 动态型:如果列(即使只有一列)定义为动态的(xblob, xtext, varchar 等数据类型),这时 MyISAM 就自动使用动态型,虽然动态型的表占用了比静态型表较少的空间,但带来了性能的降低,因为如果某个字段的内容发生改变则其位置很可能需要移动,这样就会导致碎片的产生,随着数据变化的增多,碎片也随之增加,数据访问性能会随之降低。
    • 压缩型:如果在数据库中创建在整个生命周期内只读的表,则应该使用 MyISAM 的压缩型表来减少空间的占用。

对于因碎片增加而降低数据访问性这个问题,有两种解决办法:

InnoDB 和 MyISAM 的比较

bTree vs b+Tree

B Tree 指的是 Balance Tree,也就是平衡树,平衡树是一颗查找树,并且所有叶子节点位于同一层。 B+ Tree 是 B 树的一种变形,它是基于 B Tree 和叶子节点顺序访问指针进行实现,通常用于数据库和操作系统的文件系统中。 B+ 树有两种类型的节点:内部节点(也称索引节点)和叶子节点,内部节点就是非叶子节点,内部节点不存储数据,只存储索引,数据都存在叶子节点。

  1. B+树的层级更少:相较于 B 树 B+每个非叶子节点存储的关键字数更多,树的层级更少所以查询数据更快;

  2. B+树查询速度更稳定:B+所有关键字数据地址都存在叶子节点上,所以每次查找的次数都相同所以查询速度要比 B 树更稳定;

  3. B+树天然具备排序功能:B+树所有的叶子节点数据构成了一个有序链表,在查询大小区间的数据时候更方便,数据紧密性很高,缓存的命中率也会比 B 树高。

  4. B+树全节点遍历更快:B+树遍历整棵树只需要遍历所有的叶子节点即可,,而不需要像 B 树一样需要对每一层进行遍历,这有利于数据库做全表扫描。

B 树相对于 B+树的优点是,如果经常访问的数据离根节点很近,而 B 树的非叶子节点本身存有关键字其数据的地址,所以这种数据检索的时候会要比 B+树快。