MySQL 是第一款提出存储引擎概念的数据库管理系统，这也成为 MySQL 的主要特征。之后，MariaDB 扩展了存储引擎的 API，并且引入了一些第三方存储引擎，从而提供了对第三方存储引擎的支持。
存储引擎的想法之后逐渐被其它数据库所使用，例如 MangoDB 长期支持它们，而 PostgreSQL 12 也引入了对存储引擎的基本支持。
这里我们将讨论 MariaDB 和 MySQL 中存在哪些存储引擎。它们不支持完全相同的存储引擎，因此本文内容也可能有助于评估项目是否应该使用 MariaDB 和 MySQL。
1] 什么是存储引擎
使用存储引擎的想法很简单，就是 MySQL 不需要关心如何物理读取数据、维护索引以及缓存数据等物理文件操作，而是将这部分功能交由一种被称为存储引擎的特殊插件来完成。
这就给存储引擎提供了很大的灵活性。当 MySQL 向存储引擎发出请求时”存储引擎，请插入这一行”，存储引擎会完成之后的所有操作，只需要报告执行成功或失败。
MariaDB 作为 MySQL 5.1 的一个分支开始了它的旅程，因此它从一开始就支持存储引擎。它还默认包含一些由第三厂商开发的的存储引擎，尽管这些存储引擎是不包含在 MySQL 中或不受 Oracle 支持的。
2] 主要存储引擎
我们首先来介绍一下 MariaDB 和 MySQL 常用的存储引擎。
MariaDB 和 MySQL 会默认选择使用一种存储引擎，一旦选择了默认值，系统会使用该存储引擎来构建数据表。除非有特殊需求时，才会使用其它引擎。
一般不要在数据库中使用多个引擎，而众多引擎之中，InnoDB 通常是最佳选择。
InnoDB/XtraDB
InnoDB 最初是为了实现 MySQL 中缺少的功能而开发的，特别是事务和外键。如今它是默认选项，不了解存储引擎的用户就使用 InnoDB。这是有充分理由的，因为 InnoDB 仍然是唯一支持事务的存储引擎，其性能特点使其成为一般情况下的最佳选择。
而所谓 XtraDB 仅出现在 Percona Server 和非常旧的 MariaDB 版本中。XtraDB 是 InnoDB 的 Percona 分支。
RocksDB / MyRocks（MariaDB, Percona Server）
该引擎最初由 Facebook 创建，提供了 MySQL 和 RocksDB 技术之间的接口。换句话说，常规 SQL 和事务可以在 RocksDB 技术之上使用。MyRocks 随 MariaDB（名称为 RocksDB）和 Percona Server 附带，不随 MySQL 附带。 MariaDB 和 Percona 团队都独立修改了RocksDB/MyRocks。
RocksDB/MyRocks 的主要目的是提供 InnoDB 的替代方案，它使用更少的资源并更好地压缩数据。它之所以没有被广泛使用，是因为……大多数公司都不是 Facebook，多数公司可能不太关心 SSD 设备的使用寿命。但是，如果资源使用对于公司来说是个问题，并且配置和查询已经得到很好的优化，那么 RocksDB/MyRocks 是可以考虑的解决方案之一。
ColumnStore （MariaDB）
MariaDB 可以用作旨在横向扩展的列式数据库。我们可以通过使用 ColumnStore 存储引擎来做到这一点。ColumnStore 可以在单个节点上运行，也可以在 Galera 集群上运行。ColumnStore 集群具有用户模块、性能模块以及本地或外部存储。
尽管其架构特殊，但 ColumnStore 可以与其他存储引擎结合使用。因此我们可以将列式数据与纯关系表（例如 InnoDB 表）连接起来。在我看来，这是使用ColumnStore 而不是专门的列式数据库的主要原因。
ColumnStore 源自较旧的技术 InfiniDB，它是 MySQL 的一个分支。MariaDB 收购了 InfiniDB，最初用它来制作单独的 MariaDB 版本。在 MariaDB 10.5 版本中，ColumnStore 成为常规 MariaDB 版本的一部分。
NDB Cluster （MySQL）
NDB（或 NDBCLUSTER）是一种存储引擎，允许形成内存数据库集群，并将数据保存在磁盘上。 它对数据进行分片，每个分片可以有多个副本以实现冗余。 尽管它有 SQL 接口，但它的数据模型是键/值对。在 NDB 集群中，MySQL只是整体架构的一部分。 集群的组件包括：
- SQL节点：带有NDB引擎的SQL服务器
- 存储节点，每个节点都是一个分片副本
- 组织集群的管理节点
NDB 仅运行在 MySQL 的修改版本上。常规 MySQL 二进制文件不能用于 NDB。 这些节点类型中的每一种都通过与 NDB 一起分发的一些实用程序进行管理。与常规 MySQL 相比，NDB 有很多限制。
RonDB
NDB 有一个由它自己的创建者发起的开源分支。它称为 RonDB，是 Hopsworks 的一部分。它定期包含 MySQL Cluster 的最新更改以及一些独特的改进。
3] 其它有用的存储引擎
这些存储引擎并不适合一般用途，但在某些特定情况下非常有用。
MEMORY
MEMORY 将行写入……内存中。当 MariaDB/MySQL 重新启动或崩溃时，这些表的内容将丢失。另一个限制是不支持 BLOB 和 TEXT 列。所以 MEMORY 主要用作缓存。
有些人认为存在更好的缓存技术，但实际上可以存在不同级别的缓存。使用 Redis 或 Memcached 之类的东西来存储查询结果是有意义的。 但是您可能有一个查询，该查询生成的结果通常会联接到其他表或用作子查询。 在这种情况下，将这些结果缓存在 MEMORY 表中可能是一个好主意。
CONNECT （MariaDB）
一般来说，CONNECT 允许我们像本地表一样读写远程数据源。
特别是，它可以访问以下类别的数据源：
- 远程数据库
- MariaDB/MySQL 原生协议
- ODBC
- 数据库连接
- MongoDB
- 网络 API
- 文件（CSV、JSON、XML、HTML、自定义日志等）
- 特殊来源（目录内容、MAC 地址、Windows WMI）
- 查询转换（透视、原始数据到汇总、汇总到原始数据）
SPIDER （MariaDB）
SPIDER 是一个用于实现数据分片的存储引擎，随 MariaDB 一起提供。它最初是为 MySQL 构建的，其网站用于通过 SPIDER 分发 MySQL 版本。现在已经找不到 SPIDER 网站了，所以我想现在它只能在 MariaDB 中使用。
如果以最基本的方式使用，SPIDER 会链接到远程 MariaDB 或 MySQL 表。但 SPIDER 支持分区，并且它允许将每个分区链接到不同的表，可能位于不同的服务器上。通过这种方式，我们可以拥有相同的表，但在不同的服务器上，包含不同的数据集。
此外，目前 MariaDB 并不在内部并行查询，甚至对于连接或分区表也是如此。但是，SPIDER 允许创建指向多个本地表或本地分区表的分区的分区表。于是，当我们对 SPIDER 表运行查询时，它将被并行化。对于我们读取的每个分区，SPIDER 将启动与本地主机的单独连接。
BLACKHOLE
BLACKHOLE 表类似于 Linux /dev/null 文件。它总是空的，尝试将数据插入 BLACKHOLE 不会返回任何错误，但表将保持为空。但是，针对 BLACKHOLE 表的 INSERT 操作将写入二进制日志，并将写入副本（如果有）。因此，如果主表上的表为 BLACKHOLE 类型，而副本上的表为 InnoDB 类型，则我们可以在主表上运行 INSERT，仅在副本中插入行。 反之亦然，如果主表上的表是 InnoDB，副本上的表是 BLACKHOLE，则我们只能在主表上写入数据。
EXAMPLE （MySQL, Percona Server）
EXAMPLE 是一个不执行任何操作的示例存储引擎，并且默认情况下不进行编译。有兴趣开发新存储引擎的人可以使用 EXAMPLE 作为样板。 MySQL 源代码包括 EXAMPLE ，但该引擎几年前已从 MariaDB 中删除。
4] 经典存储引擎
这些存储引擎已经非常老，但仍然存在于 MariaDB 或 MySQL 中。依然可能有一些理由需要使用它们，但很少。如果我们仍然使用它们，我们可能应该考虑将表迁移到 InnoDB 或其他存储引擎。
MyISAM
这是 MariaDB 和 MySQL 附带的最古老的存储引擎。在被InnoDB取代之前，它曾经是默认的存储引擎。
MyISAM 不是事务性的，它有一个称为键缓冲区的索引缓存，并且依赖于文件系统缓冲区来存储数据。当 MariaDB 崩溃时，MyISAM 会丢失所有尚未刷新到磁盘的数据。如果崩溃时仅部分写入某些数据，则表会损坏并且部分写入的数据会丢失。
MyISAM支持压缩，并且可以很好地压缩数据。然而，压缩表是只读的，在压缩表之前需要停止DBMS。
MERGE
MERGE 或 MRG_MyISAM 的开发目的是将多个 MyISAM 表视为一个表。几年前，当 MyISAM 超出了操作系统规定的文件大小限制时，这一点特别有用。但如今这个问题极不可能发生。
MariaDB 和 MySQL 多年来一直支持分区表和视图。这些功能当然可以与 MyISAM 表一起使用，因此不再需要 MERGE。
CSV
CSV 存储引擎将 CSV 文件视为表。 当我们创建一个新表时，我们可以基于现有文件，或者让引擎自动创建一个新文件。
CSV 有非常重要的限制：它不支持索引，也不能存储 NULL 值。
在 MariaDB 中，CSV 被 CONNECT 取代，但它在 MySQL 中仍然有用。当 log_output=FILE 时，MariaDB 和 MySQL 都将其用于慢日志和普通日志（不推荐使用）。