0 存储引擎的意义
为什么是可插拔式的？
可插拔存储引擎体系结构使
- 数据库专业人员可以为特定业务需求选型合适的存储引擎
- 完全不受管理任何特定应用程序编码需求的需要
这种高效的模块化体系结构为那些希望专门针对特定应用程序需求（例如数据仓库，事务处理或高可用性情况）的用户提供了巨大的好处，同时享有利用独立于任何一个的一组接口和服务的优势存储引擎。
MySQL服务器体系结构将应用程序开发者和DBA与存储级别的所有底层实现细节隔离，从而提供了一致且简单的应用程序模型和API。因此，尽管跨不同的存储引擎具有不同的功能，但应用程序不受这些差异的影响。
MySQL架构
具有可插拔式存储引擎的MySQL体系结构
Connectors 各种语言的客户端应用
Connection Pool 为应用层，负责连接、验证等功能
应用层，负责和客户端,用户交互，需要和不同的客户端和中间服务器进行交互，建立连接，记住连接的状态，响应它们的请求，返回数据和控制信息（错误信息，状态码等）。
NoSQL Interface、SQL Interface、Parser、Optimizer、Cache & Buffers、Storage Engines——逻辑层
逻辑层，负责具体的查询处理、事务管理、存储管理、恢复管理,以及其他的附加功能。查询处理器负责查询解析、执行，当接收到客户端的Sql查询，数据库就分配一个线程来处理它，由查询处理器生成执行计划，交由计划执行器来执行，执行器的部分操作还需要访问更底层的事务存储管理器操作数据，事务、存储管理器主要负责我们的事务管理、并发控制、存储管理，由我们的事务管理器来确保“ACID”特性，由锁管理器来控制我们的并发，由日志管理器来确保我们的数据持久化，存储管理器一般还包括一个bufer管理器，由它来确定磁盘和内存缓冲之间的数据传输。
Files& Logs 物理层
物理层，实际物理磁盘(存储)上的数据库文件。如我们的数据文件、日志文件等。
可插拔存储引擎体系结构提供了在所有基础存储引擎中通用的一组标准管理和支持服务。
存储引擎本身是数据库服务器的组件，它们实际上对在物理服务器级别维护的基础数据执行操作，规定了数据文件的组织形式。
应用程序程序员和DBA通过存储引擎上方的连接器API和服务层与MySQL数据库交互。如果应用程序更改带来了要求基础存储引擎更改的要求，或者添加了一个或多个存储引擎来支持新需求，则无需进行重大的编码或流程更改即可使工作正常进行。 MySQL服务器体系结构通过提供适用于整个存储引擎的一致且易于使用的API，使应用程序免受存储引擎的潜在复杂性的影响。
1 Isam
在读取数据方面速度很快，而且不占用大量的内存和存储资源
但不支持事务、外键、索引。
MySQL≥5.1版本中不再支持。
2 Berkeley
支持COMMIT和ROLLBACK等事务特性。
MySQL在 ≥ 5.1版本中不再支持。
3 CSV
使用该引擎的MySQL数据库表会在MySQL安装目录data文件夹中的和该表所在数据库名相同的目录中生成一个.CSV文件（所以，它可以将CSV类型的文件当做表进行处理），这种文件是一种普通文本文件，每个数据行占用一个文本行。
但是不支持索引，即使用该种类型的表没有主键列；
也不允许表中的字段为null。csv的编码转换需要格外注意。
适用场景
支持从数据库中拷入/拷出CSV文件。如果从电子表格软件输出一个CSV文件，将其存放在MySQL服务器的数据目录中，服务器就能够马上读取相关的CSV文件。同样，如果写数据库到一个CSV表，外部程序也可以立刻读取它。在实现某种类型的日志记录时，CSV表作为一种数据交换格式，特别有用。
4 MEMORY（亦称HEAP）
在内存中创建临时表来存储数据。
出发点是速度 采用的逻辑存储介质是内存。
磁盘文件只存储表结构，数据存储在内存，所以使用该种引擎的表拥有极高插入、更新和查询效率。
默认使用哈希（Hash）索引，速度比使用B+Tree快，也可使用B+树索引。
由于这种存储引擎所存储的数据保存在内存中，无法持久化！所以其保存的数据具有不稳定性，比如如果mysqld进程发生异常会造成这些数据的消失，所以该存储引擎下的表的生命周期很短，一般只使用一次。
适用场景
如果需要该数据库中一个用于查询的临时表。
