MySQL各类存储引擎介绍与适用场景

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< p="">

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 发布！