MySQL 三大常见引擎的区别 InnoDB MyISAM Memory

InnoDB

InnoDB 是 MySQL 的默认事务型引擎,也是最重要、使用最广泛的存储引擎。它被设计用来处理大量的短期事务,短期事务大部分情况是正常提交的,很少会被回滚。InnoDB 的性能和自动崩溃恢复特性,使得它在非事务型存储的需求中也很流行。除非有非常特别的原因需要使用其他的存储引擎,否则应该优先考虑 InnoDB 引擎。

InnoDB 采用 MVCC 来支持高并发,并且实现了四个标准的隔离级别。其默认级别是 REPEATABLE_READ(可重复读),并且通过间隙锁(next-key locking)策略防止幻读的出现。间隙锁使得 InnoDB 不仅仅锁定查询涉及的行,还会对索引中的间隙进行锁定,以防止幻影行的插入。

InnoDB 内部做了很多优化,包括从磁盘读取数据时采用的可预测性预读,能够自动在内存中创建 hash 索引以加速读操作的自适应哈希索引,以及能够加速插入操作的插入缓冲区等。

MyISAM

在 MySQL 5.1 及之前的版本, MyISAM 是默认的存储引擎。MyISAM 提供了大量的特性,包括全文索引、压缩、空间函数等,但 MyISAM 不支持事务和行级锁,而且有一个毫无疑问的缺陷就是崩溃后无法安全恢复。尽管 MyISAM 引擎不支持事务、不支持崩溃后的安全恢复,但它绝不是一无是处的。对于只读的数据,或者表比较小、可以忍受修复操作,则依然可以继续使用 MyISAM 引擎。

  • MyISAM 特性
    作为 MySQL 最早的存储引擎之一,MyISAM 有一下已经开发出来很多年的特性,可以满足用户的实际需求。

    • 加锁与并发
      MyISAM 对整张表加锁,而不是针对行。读取时会对需要读到的所有表加共享锁,写入时则对表加排他锁。但是在表有读取查询的同时,也可以往表中插入新记录(这被称作并发插入,CONCURRENT INSTERT)。
    • 修复
      对于 MyISAM 表,MySQL 可以手工或者自动执行检查和修复操作,但这里说的修复和事务恢复以及崩溃恢复是不同的概念。执行表的修复可能导致一些数据的丢失,而且修复操作是非常慢的。可以通过 CHECK TABLE mytable 检查表的错误,如果有错误可以通过执行 REPAIR TABLE mytable 进行修复。另外,如果 MySQL 服务器已经关闭,也可以通过 myisamchk 命令行工具进行检查和修复操作。
    • 索引特性
      对于 MyISAM 表,即使是 BLOG和TEXT等长字段,也可以基于其前 500 个字符创建索引。MyISAM 也支持全文索引,这是一种基于分词创建的索引,可以支持复杂的查询。
    • 延迟更新索引键
      创建 MyISAM 表的时候,如果指定了 DELAY_KEY_WRITE 选项,在每次修改执行完成时,不会立刻将修复的索引数据写入磁盘,而是会写到内存中的键缓冲区(in-memory-key buffer),只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入到磁盘。这种方式可以极大地提升写入性能,但是在数据库或者主机崩溃时会造成索引损坏,需要执行修复操作。延迟更新索引键的特性,可以在全局设置,也可以为单个表设置。

Memory

如果需要快速访问数据,并且数据不会被修改,重启以后丢失也没有关系,那么使用 Memory 表(以前也叫做 HEAP 表)是非常有用的。Memory 表至少比 MyISAM 表要快一个数量级,因为所有的数据都保存在内存中,不需要进行磁盘 I/O。Memory 表的结构在重启以后还会保留,但数据会丢失。

Memory 表在很多场景可以发挥好的作用:

  • 用于查找(lookup)或者映射(mapping)表,例如将邮编和州名映射的表。
  • 用于缓存周期性聚合数据的结果。
  • 用于保存数据分析中产生的中间数据。

Memory 表支持 Hash 索引,因此查找操作非常快。虽然该 Memory 表的速度非常快,但还是无法取代传动的基于磁盘的表。Memory 表是表级锁,因此并发写入的性能较低。它不支持BLOG或TEXT类型的列,并且每行的长度是固定的,所以即使制定了 VARCHAR 列,实际存储时也会转换成 CHAR,这可能导致部分内存的浪费。

如果 MySQL 在执行查询的过程中需要是用来临时表来保存中间结果,内部使用的临时表就是 Memory 表。如果中间结果太大超过了 Memory 表的限制,或者含有 BLOB 或 TEXT 字段,则临时表会转换成 MyISAM 表。

猜你喜欢

转载自blog.csdn.net/simplexingfupeng/article/details/80373646