本文地址：https://www.askmac.cn/archives/mysql-other-storage-engines.html
8.3 其它存储引擎
MySQL服务端还支持除之前所介绍之外的其它几种数据引擎（当然有些存储引擎随着各种原因，或渐渐淡出MySQL主流舞台，或被弃用，而第三方提供的存储引擎更是层出不穷，因此，这里我们就不一一列举了，只介绍官方提到的一些引擎，权当个小知识即可），基于不同版本的MySQL，其默认是否进行了编译安装启用都会有所不同，这里不会做太深入的启用介绍，因此，如果大家感兴趣，可以查看MySQL的官方手册来了解。
8.3.1 EXAMPLE存储引擎
你可以将EXAMPLE引擎作为一个最佳的”MySQL存储引擎开发”样例来进行源码学习，事实上此引擎的目的也是如此，它并非用于生产环境，其不支持任何的数据插入操作，它对于有志于开发那些自有存储引擎的开发者起到了一个示范作用。
8.3.2 MERGE存储引擎
MERGE存储引擎，这里又个称为MRG_MYISAM存储引擎。它可以将多张完全相同的MyISAM存储引擎表“合而为一”（建立一张MERGE表，其定义包含有多张表结构，列顺序，索引相同的MyISAM表）。
虽然可以合并的限制较为严格，不过如果可用的话也会有以下优点：
- 更简单的表管理
- 如果表其底层对应的MyISAM表分布如不同的磁盘，其只读的情况可获得更佳的查询速度。
- 不受操作系统文件大小限制（每个MyISAM表文件都有其大小限制）。
优点不止于此，不过也有缺点：如MERGE表不可建立FULLTEXT索引；其索引读会慢一些等。
8.3.3 FEDERATED存储引擎
FEDERATED存储引擎是在MySQL 5开始被推出的。它允许MySQL服务端可以使得客户端访问并使用来自其它MySQL服务端的表并表现得就像在访问此服务端的表一样。其中客户端不需要因这些被访问表的位置而去直接连接所在位置的服务端。
此功能的一大好处就在于我们可以使用简单查询来访问那些由不同服务端管理的表。无需连接每个服务端并分别获取每个表的数据。如，你可以对来自不同服务端的表进行表连接操作。FEDERATED存储引擎在查询优化上还有许多需要改进的地方，不过这种引擎的实现本身就是一个意义重大的功能增强。
FEDERATED存储引擎所管理的表具有以下特点：
- 每个FEDERATED表在磁盘中的数据库目录下对应有一个.frm格式文件。
- FEDERATED存储引擎不支持事务。
- FEDERATED存储引擎支持SELECT, DELETE, UPDATE和INSERT语句。
- MySQL对FEDERATED表不使用任何锁。
假如在远程主机world.example.com上存在一个world数据库，其下City表有如下定义：
CREATE TABLE City ( ID INT NOT NULL AUTO_INCREMENT, Name CHAR(35) NOT NULL, CountryCode CHAR(3) NOT NULL, District CHAR(20) NOT NULL, Population INT NOT NULL, PRIMARY KEY (ID) ) ENGINE = MyISAM;
如果world数据库可以以wuser用户名和wpass密码进行服务端登陆访问，那么我们可以在本地MySQL服务端中建立一张FEDERATED表来对远程的world.City进行访问，而我们的查询操作就像本地的查询操作一样简单。建立这张FEDERATED表时，其定义和其远程表的定义其实差不多，唯一的区别在于两处。首先需要在定义中使用ENGINE = FEDERATED项。第二，需要包括表CONNECTION定义来设置FEDERATED表的远程连接字符串。连接字符串中声明了远程表的位置以及远程服务端的连接信息。连接字符串格式如下，其中方括号中卫可选部分：
mysql://user_name[:password]@host_name[:port]/db_name/table_name
用户名(user_name)，密码(password)，以及端口号(port)定义了连接远程服务端的连接参数。而数据库名(db_name)和表名(table_name)定义了对哪张表进行访问。
使用ENGINE和CONNECTION表项，FEDERATED表FedCity定义为：
CREATE TABLE FedCity ( ID INT NOT NULL AUTO_INCREMENT, Name CHAR(35) NOT NULL, CountryCode CHAR(3) NOT NULL, District CHAR(20) NOT NULL, Population INT NOT NULL, PRIMARY KEY (ID) ) ENGINE=FEDERATED CONNECTION='mysql://wuser:wpass@world.example.com/world/City';
注意：在MySQL 5.0.13版本前，使用COMMENT作为FEDERATED表定义连接字符串设置语法项，之后则使用CONNECTION。
用户名和密码(wuser和wpass)由于在表定义中可见，因此这在多个方面会成为安全隐患：
- 用户在对FedCity表使用SHOW CREATE TABLE或SHOW TABLE STATUS时会看到COMMENT定义。而且用户在查看TABLES表信息时也会看到相关信息。为了避免此类安全事件，不要将关于FedCity的权限授予其它用户。
- FedCity表定义被存放在.frm格式文件中，用户可以读取此文件来看到用户名和密码。
查询FedCity表可以像查询其它表一样。如：
实际上，在之前对FEDERATED表的讨论中，使用“远程”这个词来描述其功能并不精确：因为FEDERATED表也可用于定义为在同一主机中运行的其他MySQL服务端上的表，甚至可以是同一个服务端上的其它表。
限制：
当然这么一个好引擎也自然有它的使用边界，以下列出了FEDERATED存储引擎所能支持和不能支持的一些特性：
- 被设定的远程服务端必须为MySQL服务端。
- 被指向的远程表必须在建立FEDERATED表并访问前已存在。
- 在建立FEDERATED表时，请避免造成指向循环。
- 不支持事务。
- FEDERATED引擎无法了解远程表是否已经被改变。如果远程端对被指向的表进行了结构或底层非数据库本身（而是系统文件）的操作修改，那么FEDERATED表的完整性就会被打破。
- FEDERATED存储引擎支持SELECT，INSERT，UPDATE，DELETE，TRUNCATE和索引。其除了DROP TABLE之外任何其他数据定义语句。当前的实现也不能使用Prepared statement。
- 其底层实现中使用了SELECT, INSERT, UPDATE和DELETE，但不使用HANDLER。
- 对于FEDERATED表的查询不会被缓存在Query Cache中。
| FEDERATED表及其性能由于大量的性能限制，FEDERATED存储引擎对于一些业务需求较高速度反应的应用并不是一个好选择。其存储引擎更对是针对那些需求较少的应用。在使用时对业务所需的性能要求需要对FEDERATED存储引擎使用前要做谨慎的评估。 |
8.3.4 ARCHIVE存储引擎
ARCHIVE存储引擎可用于将大量无索引数据以一个非常小的空间进行存储。当建立了一张ARCHIVE表，服务端会相应的在数据库目录中建立一个表格式文件。文件会以表名作文件名并以.frm为扩展名。除此之外，存储引擎会建立其它以表名打头的文件，这些文件相应有.ARZ结尾的数据文件，（MySQL 5.1.15之前以.ARM结尾的metadata元数据文件），以及性能调优操作时产生的.ARN文件。
ARCHIVE引擎支持INSERT，SELECT，但不支持DELECT, REPLACE或UPDATE。它支持ORDER BY操作，BLOB列，以及所有除了空间(sptial)数据类型之外的基本数据类型。ARCHIVE引擎支持行级锁。
存储
当数据行被插入ARCHIVE表时，行是被压缩存放的。OPTIMIZE TABLE语句可以被用来分析此表并将其以一个更小的格式进行压缩打包。这里有几种插入类型可以使用：
- INSERT语句 – INSERT语句仅将行压入一个压缩的缓冲中，而最终缓冲会在必要时刷出落地。此缓冲插入会被一个锁保护。如果使用SELECT语句的话会强制此缓冲刷出操作的发生，除非你当时使用INSERT DELAYED进行的插入（那缓冲在必要时刷出）。
注意：INSERT DELAYED 从MySQL 5.6.6开始过期，在MySQL 5.7版本中已经不支持此功能了。
- 批量插入(Bulk Insert) – 批量插入只有在其完成后才能对用户可见。除非有其它插入在同时发生，这会使得部分行数据可见。单单进行的一个批处理SELECT语句不会将行数据从缓存中刷出，除非在倒入时还有其它插入在进行。
提取数据
在查询并提取数据时，行数据被按需解压；这里没有行缓冲。SELECT操作会进行一次全表扫描：当一句SELECT发生时，首先会查看有多少行当前可用，然后读取这些行的行数。SELECT进行的是一个一致性读。
| 大量的SELECT语句在进行插入时会造成压缩数据的恶化，除非使用批量插入或延时插入，否则，许多数据由于需要解压查询因此无法进行压缩。 |
其压缩表现
ARCHIVE存储引擎比其它存储引擎降低文件存储大小达70%。对于那些不再被修改并且作为历史信息的数据来说，这极大降低了文件保存大小。此外，由于是业务数据，保留这些数据对于那些需要遵守商业和政府要求规则的企业来说也非常重要。
8.3.5 CSV存储引擎
CSV存储引擎是一种专门的存储引擎，其将所有数据以.csv格式文件进行存储。从MySQL 5.5开始，此引擎就已经经过默认编译可用了。如果是过去版本不可用的话，就需要你重启MySQL并同时配置使用 --with-csv-storage-engine命令项。当建立了一张CSV表，服务端会在数据库目录中建立一个.frm表格式文件，文件名即为表名。而存储引擎也会建立一个平文件，文件名以表名开头并使用.csv作为扩展名。当数据被存入表中，存储引擎会将数据列以逗号分隔的格式进行保存。此.csv表数据文件可以直接从底层拷贝出来并发给客户，而客户可以直接以表格工具（如Excel）打开并查看。此存储引擎不可使用索引，因此对此引擎表类具有使用限制。
和此CSV引擎所产生的文件具有相同功能作用的语句：
对于其它引擎的表，你也可以使用SELECT … INTO OUTFILE语法来以.csv文件格式建立这样一个表数据平文件，例如：
| SELECT * INTO OUTFILE ‘/var/lib/mysql-files/city.csv’ FIELDS TERMINATED BY ‘, ‘ ENCLOSED BY ‘”‘ FROM city; |
** Windows环境下，为’c:\\mysql\\city.csv’
以下为使用以上命令导出的CSV表文件：
存储引擎对比：
8.3.6 BLACKHOLE存储引擎
BLACKHOLE引擎并不实际存储任何数据。不过即便存储引擎对数据而言是一个黑洞，但表和索引都是可以创建的，且所有数据库可执行的SQL语句都可运行。数据库结构任然保留并允许存在对非存在数据信息建立的索引。由于不建立数据，又保留有结构，因此此存储引擎对于进行测试研究来说是极好的选择。其所有的针对BLACKHOLE数据库执行的SQL语句都会被记录在binary log中，且可以被复制到从库上。
Relay Slave从库：
如果你的目的是将主库的数据通过一个中间从库（这个中间库也可以和主库在一个服务器上），然后同步到一个或多个从库的话，那么中间从库使用BLACKHOLE数据库是个不错的选择。这样设计的好处在于中间从库不需要为自己保存任何数据，而主库只需要将数据传送一次，而中间从库则负责将主库传送过来的数据复制到其它多个从库，从而分担了主库的负担，流图如下：
过滤机制：
除了BACKHOLE作为一个传递者，其也可起到过滤的作用。例如，假设一个应用需要从库端有过滤规则，但将所有binary日志记录传到从库会导致网络压力太大。这种情况下，一个首先在主机上再建立一个”dummy”从库作为中转，其中转库存储引擎使用BLACKHOLE：
主服务端写binary log。“dummy“ mysqld进程作为中间从库进程应用replicate-do-* 和 replicate-ignore-* 过滤参数设置规则，并写出自己筛选后的新binary log。dummy进程不实际存储数据，因此相应的开销也非常小，即使在主机上运行，负担也不大。中间从库生成的binary log，可以继续传给之后的复制从库。
其它可能对BLACKHOLE存储引擎的使用包括：
|
8.3.7 NDB Cluster存储引擎
要使用上集群引擎是个复杂是事，而且就MySQL OCP认证来说也不需要你了解如何建立和使用NDB Cluster。不过，你还是应该大致对此引擎和其它存储引擎相比较的一些特点有作了解。
从一些文章或字面中，我们一般会看到两个术语“NDB Cluster“(或仅仅是”NDB”)和”MySQL Cluster“。NDB Cluster指的是一种集群技术且特指其存储本身，而MySQL Cluster指的是一个或多个MySQL服务端组成的一个组作为NDB Cluster引擎的“前端”进行工作。换言之，一个MySQL Cluster包含了一个或多个服务器主机的组成，其中的每一个主机又运行了多个进程，这些进程有MySQL服务端，NDB管理进程，和NDB数据库存储节点。Cluster进程也被称为“集群节点”或仅称为“节点”。
集群引擎并不是在MySQL服务端内部运行的，这些进程都会在MySQL服务端外运行（甚至可能运行在不同的服务器上）。事实上，MySQL服务端对集群进程提供了SQL接口，具体的接口实现有进程来做。而从服务端角度来看，NDB Cluster就像一个存储引擎，和MyISAM，InnoDB引擎一样。
NDB Cluster包括有几个数据库进程（节点）运行在一个或多个物理服务主机上。它以一套非共享体系（shared-nothing system）来管理一个或多个内存(in-memory)数据库。In-memory意味着每个数据库中的所有信息的处理都被保持于组成集群的服务器内存中（当然，更新最终会被写入磁盘以保证数据不会丢失）。Shared-nothing意味着集群中，两个节点间无任何硬件组件共享这样一种方式组成。
和InnoDB存储引擎一样，NDB集群引擎也是一个事务支持存储引擎。
以下列出了考虑使用MySQL Cluster的一些主要原因：
高可用(High avilability)：所有记录在多个节点上可用。如果一个节点失败（如，某个节点服务器宕机），用户可以从另一个节点上获得相同数据。数据拷贝可被分布于多个节点也使得数据复制可以在多个不同地域位置上被分布。
可伸缩性(Scalability)：如果当前的节点负载过高，我们可以增加节点且整个系统会进行重新配置以使得数据在更多节点上可用，总体降低每个节点上的负载。
高性能(High performance)：所有节点存储在内存上，这使得数据获取速度非常快。但这并不意味着当集群关闭后，数据会丢失（和MEMORY存储引擎表不同）。所有的更新会被写入磁盘，当集群重启后数据仍然可用。
Comment