MySQL 架构 - MySQL 存储引擎 - 其他存储引擎

MEMORY (HEAP)引擎

当你需要快速读取数据，在服务器重启后，也不需要改变和保存数据，使用Memory表（以前叫做HEAP 表）是非常合适的。

Memory表要比MyISAM表快上一个级别。所有的数据都放在内存中，所以查询不用等待硬盘的I/O。在服务器重启后，表结构依然存在，但是数据都会丢失。

 

下面说几个可以用到Memory表的情况。

 

• 对于查找或映射表比较适合，如 邮政编码对应的国家名称。
• 缓存定期的聚合数据。
• 分析数据时的中间结果。

Memory表支持HASH索引。这个索引可以提升查询速度。以后会详细说明HASH索引。

虽然Memory表非常快，但是对于基于存储在硬盘上的表的复制还是有问题的。它们使用表级别的锁定。并发性差。也不支持TEXT和BLOB类型。它们仅仅支持定长的数据类型，所以即使使用了varchar也会被转为char来处理，这样内存就被浪费了。

MySQL内部使用Memory引擎时，需要用到临时表来存储中间数据。如果中间数据对于Memory表太大，或者有TEXT和BLOB字段，MySQL就会把它转为MyISAM表。以后会谈到这些。

一些朋友常常把Memory表和临时表搞混，临时表使用通过CREATE TEMPORARY TABLE临时建立的表。临时表可以使用任意的存储引擎。它们和内存表是不一样的。临时表仅仅对于单独的连接可见以及在连接关闭之后，就消失了。

Archive引擎

Archive仅仅支持INSERT和SELECT语句。它也不支持索引。这就比MyISAM减少了硬盘的I/O.因为它缓存了写入的数据以及通过zlib压缩了每次增加的行。每次select查询都需要整张表的扫描。对于日志和数据采集的应用来说用Archive是完美的了。因为这类应用经常扫描整张表来分析趋势。或者你想在复制的主服务器快速插入数据。复制的从服务器可能对于相同的表使用不同的存储引擎。意思就是在从服务器上的表可以加索引来提高分析的性能。

Archivie支持行级别的锁，并且有特殊的缓存系统来提高插入的并发性。它在查询开始时获得整个表的行数，在这之后通过停止SELECT语句达到一致读的效果。在批量插入完成之前，它们都是不可见的。这些特性模仿了支持事物的存储引擎，以及MVCC的特点。但是Archive并不是支持事物的存储引擎，它仅仅是一个优化了批量插入的速度和压缩数据的引擎。

CSV引擎

CSV引擎把存有逗号分割值的CSV文件作为一个表。但是它并不支持索引。CSV允许在服务器运行的时候，随意拷入拷出数据库。如果你从电子表格中导出CSV以及把它保存在MySQL的data目录，服务器可以及时的读取他。同样的，如果你写入数据到CSV表。外部的程序也可以马上读取它。CSV表对于数据交换和特定种类的日志尤为适合。

Federated引擎

Federated引擎并不是本地存储数据，每个Federated表指向了一个远程服务器的表。也就是说实际的操作都是在远程服务器发生的。它是远程复制的技巧。

当前的这个版本有很多缺陷以及限制的地方。因为Federated的实现方式。我们可以用主键查询单行或者往远程服务器新增行。但是聚合查询，连接或者其他基本的操作性能都不是很好。

Blackhole引擎

Blackhole引擎没有任何存储的机制。它抛弃了一切的INSERT，并不去储存。然而服务器的写入语句还是会被日志记录下来。因此它们可以被复制到从服务器或者简单的保存在日志中。所以Blackhole对于复制的设置是非常有用的并且可以审核记录。

 

 

NDB Cluster引擎

在2003年,MySQL AB从索尼爱立信公司得到了NDB Cluster。它最初被设计为高速的（实时的性能需求）并有降低信息转换的错误率以及负载均衡的能力。虽然它记录到了硬盘，但是在内存中保存了数据以及针对主键查找进行了优化。MySQL添加了其他的索引方法和做了大量的优化。在MySQL5.1中，允许在硬盘上存储一些列了。

 

NDB的架构是唯一的。NDB的集群也是完全不相同的。举个例子，ORACLE的集群。NDB基础结构是基于无共享（shared-nothing）的概念。网络中并没有存储的区域或者其他大的存储方案。对于其他的集群也是一样的。一个NDB数据库由数据节点组成的，并管理节点和SQL节点（MySQL实例）。每个数据节点都保存了集群数据的一段（数据的碎片）。这一段数据被复制，因此在不同的数据节点上就有很多相同数据的拷贝。一个物理服务器专门负责降低数据错误率和高可用性。这个方面NDB和RAID有点相似。

 

管理的节点用来获取集中配置。以及负责监控和控制集群节点。所有的数据节点都是彼此连接，以及所有的MySQL服务器连接所有的数据节点。低网络延迟对NDB集群尤为重要。

 

一些要注意的事情：NDB集群是非常COOL的技术，研究它绝对能满足你的好奇心，但是许多技术人员却因为这个原因却错误的使用它。就我们的经验来说，就算很认真的学习之后，不经过一段时间的实践，许多人还是不知道t它的用途和工作方式。结果往往是浪费了很多时间，因为它不是为一般用途的存储引擎。

 

常常令人意外的是，NDB常常应用在MySQL服务器级别而不是在存储引擎的一层。因为对于NDB必须通过网络，复杂的连接以及超慢的速度来获取所有的数据。换句话说，单表的查找是非常快的。因为多数据节点都提供数据的一部分。当你为了特殊的应用来查看NDB集群的时候，这点是你应该考虑和理解的。

 

NDB集群内容非常之多，非常复杂，我们以后的教程不会说到他。你应该找到一本专门介绍它的书。对于大多数传统的应用工，它并不是适合。

 

Falcon 引擎

Jim Starkey是个数据库贡献者，他发明了Interbase, MVCC, BLOB。Falcon也是他设计的。在2006年，MySQL AB获得了Falcon技术。Jim现在已经加入了MySQL AB.

 

Falcon是专门为今天的硬件所设计的。现在的服务器一般都是64位处理器和大量的内存。但是它也能运行在配置适中的环境中。Falcon使用了MVCC以及把活动的事物都保存到了内存中。这点可以使回滚和恢复操作非常迅速。

 

Falcon现在还没有完成。所以我们并不能很权威的介绍这个引擎。即使我们已经对它进行了基准测试，但是到了它使用的那一天估计这些已经没用了。目前我们仅仅知道它的潜在应用是在线应用，但是随着时间的流失我们会更了解它。

 

solidDB 引擎

solidDB引擎是由 Solid Information Technology所设计的。网址(http://www.soliddb.com）。它是个使用MVCC并支持事物的引擎。并支持乐观和悲观的并发控制。这点没有引擎可以做的到。对于MySQL的solidDB，它完全支持外键。在很多地方都和InnoDB相似，如集群的索引。并且还支持在线的恢复策略。

 

针对MySQL的solidDB产品完全打包了solidDB，MyISAM以及MySQL服务器。在2006年末就出现这种捆绑方式，Solid将会服务和支持整个产品。它的许可证是GPL和商业授权的双许可证，对于MySQL服务器也是一样的。

 

 

PBXT (Primebase XT) 引擎

PBXT引擎是由德国汉堡的SNAP股份有限公司的Paul McCullagh开发的。它是支持事物的引擎。和其他引擎的设计是完全不一样的。其中一点不同在于它使用事物日志以及数据文件的方法，避免了预写日志（write-ahead logging）。这点会降低事物提交的消耗。架构师使PBXT有很高的写并发的能力。测试表明在一些操作上已经超过了InnoDB的性能了。PBXT使用MVCC技术完全支持外键约束，但是不支持集群索引。

 

PBXT是个彻彻底底的新的引擎，在产品环境中，它需要更进一步的证明自己。例如，它最近才实现了持久事物。

 

作为PBXT的扩展，SNAP正在写一个叫做blob streaming的基础架构。它被用在更有效地存储和获取二进制文件上。

 

 

Maria存储引擎

这个引擎是由MySQL顶尖的开发工程师开发的。包括了MySQL的创始人Michael Widenius。最初的1.0版本仅仅包含了一些计划中的特性。

 

它的任务是用来取代MyISAM。MyISAM现在作为MySQL默认的存储引擎，服务器用它完成一些任务如privilege tables，temporary tables等。下面说一下它的路线图：

• 每个表既可以是事物的也可以不是。
• 当表运行在非事物下，支持错误修复。
• 行锁以及MVCC
• 更好的BLOB处理。

 

其他的存储引擎

有许多第三方提供了存储引擎。以及有大量的满足特殊以及试验性质的引擎。（如，有一个引擎是为了查找web services）.往往这些引擎是由一两个人开发的。因为开发一个MySQL的存储引擎并不是很难。但是，大部分的引擎都没广泛的应用，因为它们的功能范围很有限。还是你自己去寻找它们吧。