MySQL 高级 - 第六章 | 存储引擎

---

上篇：第五章、逻辑架构
下篇：第七章、索引的数据结构

本文内容主要源于：bilibili-尚硅谷-MySQL高级篇

第六章 存储引擎

---

6.1 存储引擎

为了管理方便，人们打 连接管理、查询缓存、语法解析、查询优化这些并不涉及真实数据存储的功能划分为 MySQL Server 的功能，把真实存取数据的功能划分为 存储引擎 的功能。所以在 MySQL Server 完成了查询优化后，只需按照生产的 执行计划 调用底层存储引擎提供的 API，获取到数据后返回给客户端就好了。

MySQL 中提到了存储引擎的概念，简而言之，存储引擎就是指表的类型。其实存储引擎以前叫 表处理器，后来改名为 存储引擎，它的功能就是接受上层传下来的指令，然后对表中的数据进行提取或写入操作。

---

6.1.1 查看存储引擎

查看当前 MySQL 所提供的存储引擎，语法如下：

SHOW ENGINES;
或
SHOW ENGINES \G;

示例：

mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)

各字段含义：

• Engine：表示存储引擎名称
• Support：表示 MySQL 数据库管理系统是否支持该存储引擎，YES 表示支持，NO 表示不支持，DEFAULT 表示系统默认支持的存储引擎
• Comment：表示对存储引擎的说明
• Transactions：表示存储引擎是否支持事务，YES 表示支持，NO 表示不支持
• XA：表示存储引擎所支持的分布式是否符合 XA 规范，YES 表示支持，NO 表示不支持，代表着该存储引擎是否支持分布式事务
• Savepoints：表示存储引擎是否支持事务处理的保存点，YES 表示支持，NO 表示不支持，也就是说该存储引擎是否支持部分事务回滚

MySQL-8。0 支持 9 种存储引擎，分别为 MEMORY、MRG_MYISAM、CSV、FEDERATED、PERFORMANCE_SCHEMA、MyISAM、InnoDB、BLACKHOLE 和 ARCHIVE。

---

6.1.2 设置系统默认的存储引擎

查看默认的存储引擎：

SHOW VARIABLES LIKE '%storage_engine%';
# 或
SELECT @@default_storage_engine;

示例：

mysql> SHOW VARIABLES LIKE '%storage_engine%';
+---------------------------------+-----------+
| Variable_name                   | Value     |
+---------------------------------+-----------+
| default_storage_engine          | InnoDB    |
| default_tmp_storage_engine      | InnoDB    |
| disabled_storage_engines        |           |
| internal_tmp_mem_storage_engine | TempTable |
+---------------------------------+-----------+
4 rows in set (0.00 sec)

mysql> SELECT @@default_storage_engine;
+--------------------------+
| @@default_storage_engine |
+--------------------------+
| InnoDB                   |
+--------------------------+
1 row in set (0.00 sec)

修改默认的存储引擎

如果在创建表的语句中没有显式指定表的存储引擎的话，那么就会默认使用 InnoDB 作为表的存储引擎。如果我们想改变表的默认存储引擎的话，语法如下：

SET DEFAULT_STORAGE_ENGINE = MyISAM;

或者修改 my.cnf 文件：

[mysqld]
default-storage-engine=MyISAM

如果是以修改配置文件的方式，则还需要再重启服务器

systemctl restart mysql.service

---

6.1.3 设置表的存储引擎

存储引擎是负责对表中的数据进行提取和写入工作的。可以为 不同的表设置不同的存储引擎，也就是说不同的表可以有不同的物理存储结构，不同的提取和写入方式。

---

6.1.3.1 创建表时指定存储引擎

在创建表时没有指定表的存储引擎，那就会使用默认的存储引擎 InnoDB，如果想要显示指定表的存储引擎，语法如下：

CREATE TABLE 表名 (
	建表语句;
) ENGINE = 存储引擎名称;

例如：创建一个存储引擎为 MyISAM 的表

mysql> CREATE TABLE table_01 (id int) ENGINE = MyISAM;
Query OK, 0 rows affected (0.02sec)

---

6.1.3.2 修改表的存储引擎

如果表已经建好了，可以通过以下语句来修改表的存储引擎：

ALTER TABLE 表名 ENGINE = 存储引擎名称;

示例：

mysql> ALTER TABLE table_01 ENGINE = InnoDB;
Query OK, 0 rows affected (0.02sec)
Records: 0 Duplicates: 0 Warnings: 0

---

6.1.4 引擎介绍

---

6.1.4.1 InnoDB 引擎：具备外键支持功能的事务存储引擎

• MySQL 从 3.23 开始就包含 InnoDB 存储引擎，5.5 之后就默认采用 InnoDB 引擎
• InnoDB 是 MySQL 的默认事务型引擎，它被设计用来处理大量的短期（short-lived）事务，可以确保事务的完整提交（Commit）和回滚（Rollback）
• 除了增加和查询外，还需要更新、删除操作，那么，应优选选择 InnoDB 存储引擎
• 除非有非常特别的原因需要使用其它的存储引擎，否则应该 优先 考虑 InnoDB 引擎
• 数据文件结构：
  • 表名 .frm 存储表结构（MySQL-8.0 时，合并在表名 .ibd 中）
  • 表名 .ibd 存储数据和索引
• InnoDB 是 为处理巨大数据量的最大性能设计，在以前的版本中，字典数据以及元数据文件、非事务表等来存储。现在这些元数据文件被删除了。比如：.frm、.par、.trn、.isl、.db.opt 等都在 MySQL-8.0 中不存在了
• 对比 MyISAM 的存储引擎，InnoDB 写的 处理效率差一些，并且 会占用更多的磁盘空间 以保存数据和索引
• MyISAM 只缓存索引，不缓存真实数据，InnoDB 不仅缓存索引还要缓存真实数据，对内存要求较高，而且内存大小对性能有决定性的影响

InnoDB 表的优势：

InnoDB 存储引擎在实际应用中拥有诸多优势，比如操作便利、提高了数据库的性能、维护成本低等。如果由于硬件或软件的原因导致服务器崩溃，那么在重启服务器之后不需要进行额外的操作。InnoDB 崩溃恢复功能自动将之前提交的内容定型，然后撤销没有提交的进程，重启之后继续从崩溃点开始执行。

InnoDB 存储引擎在主内存中维护缓冲池，高频率使用的数据将在内存中直接被处理。这种缓存方式应用于多种信息，加速了处理进程。

在专用服务器上，物理内存中高达 80% 的部分被应用于缓冲池。如果需要将数据插入不同的表中，可以设置外键加强数据的完整性。更新或者删除数据，关联数据将会被自动更新或删除。如果试图将数据插入从表，但在主表中没有对应的数据，插入的数据将被自动移除。如果磁盘或内存中的数据出现崩溃，在使用脏数据之前，校验和机制会发出警告。当每个表的主键都设置合理时，与这些列有关的操作会被自动优化。插入、更新和删除操作通过做改变缓冲自动机制进行优化。InnoDB 不仅支持当前读写，也会缓冲改变的数据到数据流磁盘。

InnoDB 的性能优势不只存在于长时运行查询的大型表。在同一列多次被查询时，自适应哈希索引会提高查询的速度。使用 InnoDB 可以压缩表和相关的索引，可以在不影响性能和可用性的情况下创建或删除索引。对于大型文本和 BLOB 数据，使用动态行形式，这种存储布局更高效。通过查询I NFORMATION_SCHEMA 库中的表可以监控存储引擎的内部工作。在同一个语句中，InnoDB 表可以与其他存储引擎表混用。即使有些操作系统限制文件大小为 2GB,innoDB 仍然可以处理。当处理大数据量时，InnoDB兼顾 CPU，以达到最大性能。

InnoDB 的 ACID 模型：

ACID 模型是一系列数据库设计规则，这些规则着重强调可靠性，而可靠性对于商业数据和任务关键型应用非常重要。MySQL 包含类似 InnoDB 存储引擎的组件，与 ACID 模型紧密相连，这样出现意外时，数据不会崩溃，结果不会失真。如果依赖 ACID 模型，可以不使用一致性检查和崩溃恢复机制。如果拥有额外的软件保护，极可靠的硬件或者应用可以容忍一小部分的数据丢失和不一致，可以将 MySQL 设置调整为只依赖部分 ACID 特性，以达到更高的性能。

InnoDB 存储引擎与 ACID 相同作用的四个方面：

• ① 原子方面：ACID 的原子方面主要涉及 InnoDB 的事务，与 MySQL 相关的特性主要包含：
  • 自动提交设置
  • COMMIT 语句
  • ROLLBACK 语句
  • 操作 INFORMATION_SCHEMA 库中的表数据
• ② 一致性方面：ACID 模型的一致性主要涉及保护数据不崩溃的内部 InnoDB 处理过程，与 MySQL 相关的特性主要包括：
  • InnoDB 双写缓存
  • InnoDB 崩溃恢复
• ③ 隔离方面：隔离是应用于事务的级别，与 MySQL 相关特性主要包括：
  • 自动提交设置
  • SET ISOLATION LEVEL 语句
  • InnoDB 锁的低级别信息
• ④ 耐久性方面：ACID 模型的耐久性主要涉及与硬件配置相互影响的 MySQL 软件特性，由于硬件复杂多样化，耐久性方面没有具体的规则可循，与 MySQL 相关的特性有：
  • InnoDB 双写缓存 ，通过 innodb_doublewrite 配置项设置
  • 配置项 innodb_flush_log_at_trx_commit
  • 配置项 sync_binlong
  • 配置项 innodb_file_per_table
  • 存储设备的写入缓存
  • 存储设备的备用电池缓存
  • 运行 MySQL 的操作系统
  • 持续的电力供应
  • 备份策略
  • 对分布式或托管的应用，最主要的在于硬件设备的地点以及网络情况

InnoDB 的 架构：

• 缓冲池：缓冲池是主内存中的一部分空间，用来缓存已使用的表和索引数据。缓冲池使得经常被使用的数据能够直接在内存中获得，从而提高速度
• 更改缓存：更改缓存是一个特殊的数据结构，当受影响的索引页不在缓存中时，更改缓存会缓存辅助索引页的更改。索引页被其他读取操作时会加载到缓存池，缓存的更改内容就会被合并。不同于集群索引，辅助索引并非独一无二的。当系统大部分闲置时，清除操作会定期运行，将更新的索引页刷入磁盘。更新缓存合并期间，可能会大大降低查询的性能。在内存中，更新缓存占用一部分 InnoDB缓冲池。在磁盘中，更新缓存是系统表空间的一部分。更新缓存的数据类型由 innodb_change_buffering 配置项管理
• 自适应哈希索引：自适应哈希索引将负载和足够的内存结合起来，使得 InnoDB 像内存数据库一样运行，不需要降低事务上的性能或可靠性。这个特性通过 innodb_adaptive_hash_index 选项配置，或者通过 --skip-innodb_adaptive_hash_index 命令行在服务启动时关闭
• 重做日志缓存：重做日志缓存存放要放入重做日志的数据。重做日志缓存大小通过 innodb_log_buffer_size 配置项配置。重做日志缓存会定期地将日志文件刷入磁盘。大型的重做日志缓存使得大型事务能够正常运行而不需要写入磁盘
• 系统表空间：系统表空间包括 InnoDB 数据字典、双写缓存、更新缓存和撤销日志，同时也包括表和索引数据。多表共享，系统表空间被视为共享表空间
• 双写缓存：双写缓存位于系统表空间中，用于写入从缓存池刷新的数据页。只有在刷新并写入双写缓存后，InnoDB 才会将数据页写入合适的位置
• 撤消日志：撤销日志是一系列与事务相关的撤销记录的集合，包含如何撤销事务最近的更改。如果其他事务要查询原始数据，可以从撤销日志记录中追溯未更改的数据。撤销日志存在于撤销日志片段中，这些片段包含于回滚片段中
• 每一个文件的表空间：每个表一个文件的表空间是指每个单独的表空间创建在自身的数据文件中，而不是系统表空间中。这个功能通过 innodb_file_per_table 配置项开启。每个表空间由一个单独的 .ibd 数据文件代表，该文件默认被创建在数据库目录中
• 通用表空间：使用 CREATE TABLESPACE 语法创建共享的 InnoDB 表空间。通用表空间可以创建在 MySQL 数据目录之外能够管理多个表并支持所有行格式的表
• 临时表空间：用户创建的临时表空间和基于磁盘的内部临时表都创建于临时表空间。innodb_temp_data_file_path 配置项定义了相关的路径、名称、大小和属性。如果该值为空，默认会在 innodb_data_home_dir 变量指定的目录下创建一个自动扩展的数据文件
• 重做日志：重做日志是基于磁盘的数据结构，在崩溃恢复期间使用，用来纠正数据。正常操作期间，重做日志会将请求数据进行编码，这些请求会改变 InnoDB 表数据。遇到意外崩溃后，未完成的更改会自动在初始化期间重新进行

---

6.1.4.2 MyISAM 引擎：主要的非事务存储引擎

• MyISAM 提供了大量的特性，包括全文检索、压缩、空间函数（GIS）等，但 MyISAM 不支持事务、行锁、外键，有一个毫无疑问的缺陷就是 崩溃后无法安全恢复
• 5.5 之前默认的存储引擎
• 优势是访问的 速度快，对事务完整性没有要求或者以 SELECT、INSERT 为主的应用
• 针对数据统计有额外的常数存储，故而 count(*) 的查询效率很高
• 数据文件结构：
  • 表名 .frm 存储表结构
  • 表名 .MYD 存储数据
  • 表名 .MYI 存储索引
• 应用场景：只读应用或者以读为主的业务

---

6.1.4.3 Archive 引擎：用户数据存档

• archive 是 归档 的意思，仅仅支持 插入 和 查询 两种功能（行被插入后不能再修改）
• 在 MySQL-5.5 以后 支持索引 功能
• 拥有很好的压缩机制，使用 zlib 压缩库，在记录请求的时候实时的进行压缩，经常被用来作为仓库使用
• 创建 ARCHIVE 表时，存储引擎会创建名称以表名开头的文件，数据文件的扩展名为 .ARZ
• 根据英文的测试结论来看，同样数量下，Archive 表比 MyISAM 表要小大于 75%，比支持事务处理的 InnoDB 表小大于 83%
• ARCHIVE 存储引擎采用了 行级锁，该 ARCHIVE 引擎支持 AUTO_INCREMENT 列属性。AUTO_INCREMENT 列可以具有唯一索引或非唯一索引，尝试在任何其他列上创建索引会导致错误
• ARCHIVE 表 适合日志和数据采集（档案） 类应用；适合存储大量的独立的作为历史记录的数据，拥有 很高的插入速度，但是对查询的支持较差

特征	支持
B 树索引	不支持
备份/时间点恢复（在服务器中实现，而不是在存储引擎中）	支持
集群数据库支持	不支持
聚集索引	不支持
压缩数据	支持
数据缓存	不支持
加密数据（加密功能在服务器中实现）	支持
外键支持	不支持
全文检索索引	不支持

---

6.1.4.4 Blackhole 引擎：丢弃写操作，读操作会返回空内容

• Blackhole 引擎没有实现任何存储机制，它会 丢弃所有插入的数据，不做任何保存
• 但服务器会记录 Blackhole 表的日志，所以可以用于复制数据到备库，或者简单地记录到日志，但这种应用方式会碰到很多问题，故不推荐

---

6.1.4.5 CSV 引擎：存储数据时，以逗号分隔各个数据项

• CSV 引擎可以将 普通的 CSV 文件作为 MySQL 的表来处理，但不支持索引
• CSV 引擎可以作为一种 数据交换的机制，非常有用
• CSV 存储的数据直接可以在操作系统里，用文本编辑器，或者 excel 读取
• 对于数据的快速导入、导出是有明显优势的
• 数据文件结构：
  • 表名 .frm 存储表结构（MySQL-8.0 时，合并在表名 .ibd 中）
  • 表名 .CSM 元文件，用于存储表的状态和表中存在的行数
  • 表名 .CSV 存储表数据

创建 CSV 表时，服务器会创建一个纯文本数据文件，其名称以表名开头带有 .csv 扩展名，当将数据存储到表中时，存储引擎将其以逗号分隔值格式保存到数据文件中

使用该引擎创建的表必须声明每个字段不为空 NOT NULL，否则会创建表失败

---

6.1.4.6 Memory 引擎：置于内存的表

Memory 采用的逻辑介质是 内存，响应速度很快，但是当 mysqld 守护进程崩溃的时候 数据会丢失，另外，要求存储的数据是数据长度不变的格式，比如 Blob 和 Text 类型的数据不可用（长度不固定）

主要特征：

• Memory 同时 支持哈希（HASH）索引 和 B+ 树索引
  • 哈希索引相等的比较快，但是对于范围的比较慢很多
  • 默认使用哈希（HASH）索引，其速度要比使用 B 型树（BTREE）索引快
  • 如果希望使用 B 树索引，可以在创建索引时选择使用
• Memory 表至少比 MyISAM 表 要快一个数量级
• MEMORY 表的大小写是受到限制 的，表的大小主要取决于两个参数，分别是 max_rows 和 max_heap_table_size，其中，max_rows 可以在创建表时指定；max_heap_table_size 的大小默认为 16MB，可以按需要进行扩大
• 数据文件与索引文件分开存储
  • 每个基于 MEMORY 存储引擎的表实际对应一个磁盘文件，该文件的文件名与表相同，类型为 frm 类型，该文件中只存储表的结构，而其 数据文件都是存储在内存中的
  • 这样有利于数据的快速处理，提供整个表的处理效率
• 缺点：其数据易丢失，生命周期短，基于该缺陷，选在 MEMORY 存储引擎时需要特别小心

使用 MEMORY 的使用场景：

1. 目标数据比较小，而且非常 频繁的进行访问，在内存中存放数据，如果太大的数据会造成 内存溢出，可以通过参数 max_heap_table_size 控制 Memory 表的大小，限制 Memory 表的最大的大小
2. 如果 数据是临时的，而且 必须立即可用 得到，那么就可以放在内存中
3. 存储在 Memory 表中的数据如果突然间 丢失的话也没有太大的关系

---

6.1.4.7 Federated 引擎：访问远程表

Federated 引擎是访问其他 MySQL 服务器的一个 代理，尽管该引擎看起来提供了一种很好的 跨服务器的灵活性，但也经常带来问题，因此 默认是禁用的。

---

6.1.4.8 Merge 引擎：管理多个 MyISAM 表结构的表集合

MERGE 存储引擎是一组 MyISAM 表的组合，这些 MyISAM 表必须结构完全相同，MERGE 表本身并没有存储数据，对 MERGE 类型的表可以进行查询、更新、删除操作，这些操作实际上是对内部的 MyISAM 表进行的。

对于 MERGE 类型表的插入操作，是通过 INSERT_METHOD 子句定义插入的表，可以有 3 个不同的值，使用 FIRST 或 LAST 值使得插入操作被相应地作用在第一或者最后一个表上，不定义这个子句或者定义为 NO，表示不能对这个 MERGE 表执行插入操作。

可以对 MERGE 表进行 DROP 操作，但是这个操作只是删除 MERGE 表的定义，对内部的表是没有任何影响的。

下面是一个创建和使用 MERGE 表的示例：

创建 3 个测试表 order_1990，order_1991，order_a11，其中 order_a11 是前两个表的 MERGE表：

示例：

create table order_1990(
	order_id int,
	order_money double(10,2),
	order_address varchar(50),
	primary key (order_id)
)engine = myisam default charset=utf8;

create table order_1991(
	order_id int,
	order_money doub1e(10,2),
	order_address varchar(50),
	primary key (order_id)
)engine = myisam default charset=utf8;

create table order_a11(
	orde_id int,
	order_money doub1e(10,2),
	order_address varchar(50),
	primary key (order_id)
)engine = merge union = (order_1990,order_1991) INSERT_METHOD=LAST default charset=utf8;

分别向两张表中插入数据

示例：

insert into order_1990 values(1,100.0,'北京');
insert into order_1990 values(2,100.0,'上海');

insert into order_1991 values(10,200.0,'北京');
insert into order_1991 values(11,200.0,'上海');

查询 3 张表中的数据

order_1990中的数据：

mysql> SELECT * FROM order_1990;
+----------+-------------+---------------+
| order_id | order_money | order_address |
+----------+-------------+---------------+
|        1 |      100.00 | 北京          |
|        2 |      100.00 | 上海          |
+----------+-------------+---------------+
2 rows in set (0.00 sec)

order_1991中的数据：

mysql> SELECT * FROM order_1991;
+----------+-------------+---------------+
| order_id | order_money | order_address |
+----------+-------------+---------------+
|       10 |      200.00 | 北京          |
|       11 |      200.00 | 上海          |
+----------+-------------+---------------+
2 rows in set (0.00 sec)

order_a11中的数据：

mysql> SELECT * FROM order_a11;
+----------+-------------+---------------+
| order_id | order_money | order_address |
+----------+-------------+---------------+
|        1 |      100.00 | 北京          |
|        2 |      100.00 | 上海          |
|       10 |      200.00 | 北京          |
|       11 |      200.00 | 上海          |
+----------+-------------+---------------+
2 rows in set (0.00 sec)

往 order_all 中插入一条记录，由于在 MERGE 表定义时，INSERT_METHOD 选择的是 LAST，那么插入的数据会向最后一张表中插入

---

6.1.4.9 NDB 引擎：MySQL 集群专用存储引擎

也叫做 NDB Cluster 存储引擎，主要用于 MySQL Cluster 分布式集群环境，类似于 Oracle 的 RAC 集群。

---

6.1.5 MyISAM 和 InnoDB

MySQL-5.5 之前的默认存储引擎是 MyISAM，5.5 之后改为了 InnoDB

首先对于 InnoDB 存储引擎，提供了良好的事务管理，崩溃修复能力和并发控制，因为 InnoDB 存储引擎 支持事务，所以对于要求事务完整性的场合需要选择 InnoDB，比如数据操作除插入和查询之外还包含有很多更新、删除操作，像财务系统对数据准确性要求较高的系统，缺点是其 读写效率稍差，占用的数据空间相对比较大。

其次对于 MyISAM 存储引擎，如果是 小型应用，系统以 读操作和插入操作为主，只有很少的更新、删除操作，并且对事务的要求没有那么高，则可以选择这个存储引擎。MyISAM 存储引擎的优势在于 占用空间小、处理速度快；缺点是 不支持事务 的完整性和并发性

这两种引擎各有特点，可以针对不同的数据表选择不同的存储引擎。

对比项	MyISAM	InnoDB
外键	不支持	支持
事务	不支持	支持
行表锁	表锁，即使操作一条记录也会锁住整个表，不适合高并发的操作	行锁，操作时只锁某一行，不对其它行有影响，适合高并发的操作
缓存	之缓存索引，不缓存真实数据	不仅缓存索引还要缓存真实数据，对内存要求较高，而且内存大小对性能有决定性的影响
自带系统表使用	Y	N
关注点	性能：节约资源、消耗少、简单业务	事务：并发写、事务、更大资源
默认安装	Y	Y
默认使用	N	Y

---

6.1.6 存储引擎的选择

在选择存储引擎时，应该根据应用系统的特点选择合适的存储引擎。对于复杂的应用系统,还可以根据实际情况选择多种存储引擎进行组合。以下是几种常用的存储引擎的使用环境。

• InnoDB：是 MySQL 的默认存储引擎，用于事务处理应用程序，支持外键。如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询意外，还包含很多的更新、删除操作，那么 InnoDB 存储引擎是比较合适的选择。InnoDB 存储引擎除了有效的降低由于删除和更新导致的锁定，还可以确保事务的完整提交和回滚，对于类似于计费系统或者财务系统等对数据准确性要求比较高的系统，InnoDB 是最合适的选择
• MyISAM：如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高，那么选择这个存储引擎是非常合适的
• Archive：用于存储和检索大量的归档数据，只支持 INSERT 和 SELECT 操作（不支持 DELETE 或 UPDATE），使用行级锁定和压缩存储，以节省空间，适合日志和数据采集（档案）
• CSV：存储数据为 CSV 格式的文件，可以使用文本编辑器或其他支持 CSV 的工具进行查看和编辑
• MEMORY：将所有数据保存在 RAM 中，在需要快速定位记录和其他类似数据环境下，可以提供几块的访问 MEMORY 的缺陷就是对表的大小有限制，太大的表无法缓存在内存中，其次是要确保表的数据可以恢复，数据库异常终止后表中的数据是可以恢复的。MEMORY 表通常用于更新不太频繁的小表，用以快速得到访问结果
• MERGE：用于将一系列等同的 MyISAM 表以逻辑方式组合在一 起，并作为一个对象引用他们。MERGE 表的优点在于可以突破对单个 MyISAM 表的大小限制，并且通过将不同的表分布在多个磁盘上，可以有效的改善 MERGE 表的访问效率。这对于存储诸如数据仓储等 VLDB 环境十分合适

---

上篇：第五章、逻辑架构
下篇：第七章、索引的数据结构