1. 引擎的介绍 

Isam

该引擎在读取数据方面速度很快，而且不占用大量的内存和存储资源；但是 Isam 不支持事务处理、不支持外键、不能够容错、也不支持索引。
该引擎在包括 MySQL 5.1 及其以上版本的数据库中不再支持。

Berkeley：

该存储引擎支持 COMMIT 和 ROLLBACK 等事务特性。
该引擎在包括 MySQL 5.1 及其以上版本的数据库中不再支持。

CSV:

使用该引擎的 MySQL 数据库表会在 MySQL 安装目录 data 文件夹中的和该表所在数据库名相同的目录中生成一个.CSV 文件（所以，它可以将 CSV 类型的文件当做表进行处理），这种文件是一种普通文本文件，每个数据行占用一个文本行。该种类型的存储引擎不支持索引，即使用该种类型的表没有主键列；另外也不允许表中的字段为 null。csv 的编码转换需要格外注意。

场景：

这种引擎支持从数据库中拷入 / 拷出 CSV 文件。如果从电子表格软件输出一个 CSV 文件，将其存放在 MySQL 服务器的数据目录中，服务器就能够马上读取相关的 CSV 文件。同样，如果写数据库到一个 CSV 表，外部程序也可以立刻读取它。在实现某种类型的日志记录时，CSV 表作为一种数据交换格式，特别有用。

HEAP（也称为 MEMORY）:

该存储引擎通过在内存中创建临时表来存储数据。每个基于该存储引擎的表实际对应一个磁盘文件，该文件的文件名和表名是相同的，类型为.frm。该磁盘文件只存储表的结构，而其数据存储在内存中，所以使用该种引擎的表拥有极高的插入、更新和查询效率。这种存储引擎默认使用哈希（HASH）索引，其速度比使用 B -+Tree 型要快，但也可以使用 B 树型索引。由于这种存储引擎所存储的数据保存在内存中，所以其保存的数据具有不稳定性，比如如果 mysqld 进程发生异常、重启或计算机关机等等都会造成这些数据的消失，所以这种存储引擎中的表的生命周期很短，一般只使用一次。

场景：如果需要该数据库中一个用于查询的临时表。

BLACKHOLE（黑洞引擎）:

该存储引擎支持事务，而且支持 mvcc 的行级锁，写入这种引擎表中的任何数据都会消失，主要用于做日志记录或同步归档的中继存储，这个存储引擎除非有特别目的，否则不适合使用。

BLACKHOLE（黑洞引擎）:

场景 1：

使用 BLACKHOLE 存储引擎的表不存储任何数据，但如果 mysql 启用了二进制日志，SQL 语句被写入日志（并被复制到从服务器）。这样使用 BLACKHOLE 存储引擎的 mysqld 可以作为主从复制中的中继重复器或在其上面添加过滤器机制。例如, 假设你的应用需要从服务器侧的过滤规则，但传输所有二进制日志数据到从服务器会导致较大的网络流量。在这种情况下，在主服务器主机上建立一个伪从服务器进程。

场景 2：

如果配置一主多从的话，多个从服务器会在主服务器上分别开启自己相对应的线程，执行 binlogdump 命令而且多个此类进程并不是共享的。为了避免因多个从服务器同时请求同样的事件而导致主机资源耗尽，可以单独建立一个伪的从服务器或者叫分发服务器。

ARCHIVE:

区别于 InnoDB 和 MyISAM 这两种引擎，ARCHIVE 提供了压缩功能，拥有高效的插入速度，但是这种引擎不支持索引，所以查询性能较差一些。archive 存储引擎支持 insert、replace 和 select 操作，但是不支持 update 和 delete。

场景 1：存储引擎基本上用于数据归档；它的压缩比非常的高，存储空间大概是 innodb 的 10-15 分之一所以它用来存储历史数据非常的适合，由于它不支持索引同时也不能缓存索引和数据，所以它不适合作为并发访问表的存储引擎。

场景 2：由于高压缩和快速插入的特点 Archive 非常适合作为日志表的存储引擎，但是前提是不经常对该表进行查询操作。

PERFORMANCE_SCHEMA：

该引擎主要用于收集数据库服务器性能参数。这种引擎提供以下功能：提供进程等待的详细信息，包括锁、互斥变量、文件信息；保存历史的事件汇总信息，为提供 MySQL 服务器性能做出详细的判断；对于新增和删除监控事件点都非常容易，并可以随意改变 mysql 服务器的监控周期，例如（CYCLE、MICROSECOND）。MySQL 用户是不能创建存储引擎为 PERFORMANCE_SCHEMA 的表。

场景：DBA 能够较明细得了解性能降低可能是由于哪些瓶颈。

memory

出发点是速度 采用的逻辑存储介质是内存

Merge

Merge 允许将一组使用 MyISAM 存储引擎的并且表结构相同（即每张表的字段顺序、字段名称、字段类型、索引定义的顺序及其定义的方式必须相同）的数据表合并为一个表，方便了数据的查询。

场景：MySQL 中没有物化视图，视图的效率极低，故数据仓库中数据量较大的每天、每周或者每个月都创建一个单一的表的历史数据的集合可以通过 Merge 存储引擎合并为一张表。

Federated

该存储引擎可以不同的 Mysql 服务器联合起来，逻辑上组成一个完整的数据库。
这种存储引擎非常适合数据库分布式应用。
Federated 存储引擎可以使你在本地数据库中访问远程数据库中的数据，针对 federated 存储引擎表的查询会被发送到远程数据库的表上执行，本地是不存储任何数据的。

场景：dblink。

缺点：

1. 对本地虚拟表的结构修改，并不会修改远程表的结构

2.truncate 命令，会清除远程表数据

3. drop 命令只会删除虚拟表，并不会删除远程表

4. 不支持 alter table 命令

5. select count(), select  from limit M, N 等语句执行效率非常低，数据量较大时存在很严重的问题，但是按主键或索引列查询，则很快，如以下查询就非常慢（假设 id 为主索引）

select id from db.tablea where id >100 limit 10 ;

而以下查询就很快：

select id from db.tablea where id >100 and id<150

6.  如果虚拟虚拟表中字段未建立索引，而实体表中为此字段建立了索引，此种情况下，性能也相当差。但是当给虚拟表建立索引后，性能恢复正常。

7. 类似 where name like “str%” limit 1 的查询，即使在 name 列上创建了索引，也会导致查询过慢，是因为 federated 引擎会将所有满足条件的记录读取到本，再进行 limit 处理。

Cluster/NDB

该存储引擎用于多台数据机器联合提供服务以提高整体性能和安全性。适合数据量大、安全和性能要求高的场景。

CAP 理论。CAP 理论(Brewer’s CAP Theorem)，是说 Consistency(一致性), Availability(可用性), Partition tolerance(分布) 三部分在系统实现只可同时满足二点，没法三者兼顾。如果对 ” 一致性 ” 要求高，且必需要做到 ” 分区 ”，那么就要牺牲可用性; 而对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。

InnoDB

适用于更新密集型，支持事务，自动灾难恢复，行锁，外键
该存储引擎为 MySQL 表提供了 ACID 事务支持、系统崩溃修复能力和多版本并发控制（即 MVCC Multi-Version Concurrency Control）的行锁
支持自增长列（auto_increment）, 自增长列的值不能为空，如果在使用的时候为空则自动从现有值开始增值，如果有但是比现在的还大，则直接保存这个值
支持外键（foreign key）, 外键所在的表称为子表而所依赖的表称为父表。
该引擎在 5.5 后的 MySQL 数据库中为默认存储引擎。

MyISAM

不支持事务，适用于选择密集型，插入密集型，mysql 默认的引擎
该引擎基于 ISAM，除了提供 ISAM 所没有的索引和字段管理等大量功能
MyISAM 还使用一种表锁机制来优化多个并发读写操作，但需要经常运行 OPTIMIZE TABLE 命令，来恢复被更新机制所浪费的空间，否则碎片也会随之增加，最终影响数据访问性能。
还有一些有用的扩展，例如用来修复数据库文件的 MyISAM Chk 工具和用来恢复浪费空间的 MyISAM Pack 工具
MyISAM 强调了快速读取操作，主要用于高负载的 select，这可能也是 MySQL 深受 Web 开发的主要原因：在 Web 开发中进行的大量数据操作都是读，所以大多数虚拟主机提供商和 Internet 平台提供商（Internet Presence Provider，IPP）只允许使用 MyISAM 格式。

MyISAM 类型的表支持三种不同的存储结构：静态型、动态型、压缩型。

• 静态表(默认的存储格式) 表中的字段都是非变长字段，这样每个记录都是固定长度的，这样存储

  • 优点: 非常迅速，易缓存，出现故障容易恢复
  • 缺点: 占用的空间通常比动态表多。静态表在数据存储时会根据列定义的宽度定义补足空格，但是在访问的时候并不会得到这些空格，这些空格在返回给应用之前已经去掉。同时需要注意：在某些情况下可能需要返回字段后的空格，而使用这种格式时后面到空格会被自动处理掉。

• 动态表 包含变长字段，记录非固定长度的

  • 优点: 占用空间较少
  • 缺点: 频繁更新删除记录会产生碎片，需要定期执行 OPTIMIZE TABLE 或myisamchk -r改善性能，并且出现故障的时候恢复相对比较困难
• 压缩表 由 myisamchk 工具创建，占据非常小空间，因为每条记录都是被单独压缩，所以只有非常小的访问开支

第三方存储引擎：

Infobright

mysql 的列存储引擎，适用于数据分析和数据仓库设计。

优点:

1. 查询性能高        – 比普通 Mysql 数据库引擎(MyISAM、InnoDB)  快 5 -60 倍.

2. 存储数据量大   – 能存储的数据量特别大.

3. 高压缩比             – 与普通数据库存放的数据文件相比, 可以达到 55:1

4. 不需要建立索引  – 省去了大量建立索引的时间.(对于我们非常有优势)

缺点:

1. 不能高并发. 最多 10 个并发

2.Infobright 分两个版本: 社区版(ICE, 免费)、企业版(IEE, 收费), 社区版在添加数据时, 只支持 loaddata , 而不支持.insert,update ,delete . 企业版, 则全部支持.

TokuDB

支持数据压缩，支持高速写入的一个引擎，但是不适合 update 多的场景。

XtraDB、PBXT

是 Percona 公司基于 InnoDB 的一个改进版本

2. 常用两种引擎的选择

MyISAM 与 InnoDB

InnoDB 和 MyISAM 是许多人在使用 MySQL 时最常用的两个表类型，这两个表类型各有优劣，视具体应用而定。

基本的差别为：MyISAM 类型不支持事务处理等高级处理，而 InnoDB 类型支持。MyISAM 类型的表强调的是性能，其执行数度比 InnoDB 类型更快，但是不提供事务支持，而 InnoDB 提供事务支持以及外部键等高级数据库功能。

所以从宏观来讲，事务数据库关注细节，而数据仓库关注高层次的聚集，所以，InnoDB 更适合作为线上的事务处理，而 MyISAM 更适合作为 ROLAP 型数据仓库。

InnoDB 引擎适合线上事物型数据库：

1.InnoDB 引擎表是基于 B + 树的索引组织表(IOT)；

2. 每个表都需要有一个聚集索引(clustered index)；

3. 所有的行记录都存储在 B + 树的叶子节点(leaf pages of the tree)；

4. 基于聚集索引的增、删、改、查的效率相对是最高的；

5. 如果我们定义了主键(PRIMARY KEY)，那么 InnoDB 会选择器作为聚集索引；

6. 如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索引作为主键索引；

7. 如果也没有这样的唯一索引，则 InnoDB 会选择内置 6 字节长的 ROWID 作为隐含的聚集索引(ROWID 随着行记录的写入而主键递增，这个 ROWID 不像 ORACLE 的 ROWID 那样可引用，是隐含的)。

MYISAM 引擎适用于 ROLAP 数据仓库：

1. 读取效率：数据仓库的高并发上承载的大部分是读，MYISAM 强调的是性能，每次查询具有原子性, 其执行数度比 InnoDB 类型更快。

2. 存储空间：MyISAM：MyISAM 的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。InnoDB：需要更多的内存和存储，它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引。

3. MyISAM 可移植性备份及恢复：MyISAM：数据是以文件的形式存储，所以在跨平台的数据转移中会很方便。在备份和恢复时可单独针对某个表进行操作。InnoDB：免费的方案可以是拷贝数据文件、备份 binlog，或者用 mysqldump，在数据量达到几十 G 的时候就相对痛苦了。移植过程中 MyISAM 不受字典数据的影响。

4. 从接触的应用逻辑来说，select count(*) 和 order by 是最频繁的，大概能占了整个 sql 总语句的 60% 以上的操作，而这种操作 Innodb 其实也是会锁表的，很多人以为 Innodb 是行级锁，那个只是 where 对它主键是有效，非主键的都会锁全表的。但 MYISAM 对于 count 操作只需要在元数据中读取，不用扫表。

5. 如果和 MyISAM 比 insert 写操作的话，Innodb 还达不到 MyISAM 的写性能，如果是针对基于索引的 update 操作，虽然 MyISAM 可能会逊色 Innodb, 但是那么高并发的写，从库能否追的上也是一个问题，且不建议数据仓库中频繁 update 数据。

6. 如果是用 MyISAM 的话，merge 引擎可以大大加快数据仓库开发速度，非常适合大项目总量约几亿的 rows 某一类型 (如日志，调查统计) 的业务表。

7. 全文索引：MyISAM：支持 FULLTEXT 类型的全文索引。InnoDB：不支持 FULLTEXT 类型的全文索引，但是 innodb 可以使用 sphinx 插件支持全文索引，并且效果更好。

8. 表主键：MyISAM：允许没有任何索引和主键的表存在，索引都是保存行的地址。InnoDB：如果没有设定主键或者非空唯一索引，就会自动生成一个 6 字节的主键(用户不可见)，数据是主索引的一部分，附加索引保存的是主索引的值。

9. 对于 AUTO_INCREMENT 类型的字段，InnoDB 中必须包含只有该字段的索引，但是在 MyISAM 表中，可以和其他字段一起建立联合索引。

10. MyISAM 不支持外键，需通过其他方式弥补。

根据引擎特性的优化

如何对 InnoDB 引擎的表做最优的优化：

1. 使用自增列 (INT/BIGINT 类型) 做主键，这时候写入顺序是自增的，和 B + 数叶子节点分裂顺序一致，这时候存取效率是最高的

2. 该表不指定自增列做主键，同时也没有可以被选为主键的唯一索引(上面的条件)，这时候 InnoDB 会选择内置的 ROWID 作为主键，写入顺序和 ROWID 增长顺序一致

ps: 多出引用，不一一标注。

本文由博客一文多发平台 OpenWrite 发布！