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）

在内存中创立长期表来存储数据。

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

每个基于该引擎的表理论对应一个磁盘文件，文件名和表名雷同，类型为.frm。
磁盘文件只存储表构造，数据存储在内存，所以应用该种引擎的表领有极高插入、更新和查问效率。

默认应用哈希（Hash）索引，速度比应用B+Tree快，也可应用B+树索引。

因为这种存储引擎所存储的数据保留在内存中，无奈长久化！所以其保留的数据具备不稳定性，比方如果mysqld过程产生异样会造成这些数据的隐没，所以该存储引擎下的表的生命周期很短，个别只应用一次。

实用场景

如果须要该数据库中一个用于查问的长期表。

5 BLACKHOLE - 黑洞引擎

反对事务，而且反对mvcc的行级锁，写入这种引擎表中的任何数据都会隐没，次要用于做日志记录或同步归档的中继存储，该存储引擎除非有特地目标，否则不适宜应用。

实用场景1

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

场景2：

如果配置一主多从的话，多个从服务器会在主服务器上别离开启本人绝对应的线程，执行binlogdump命令而且多个此类过程并不是共享的。为了防止因多个从服务器同时申请同样的事件而导致主机资源耗尽，能够独自建设一个伪的从服务器或者叫散发服务器。

ARCHIVE

区别于InnoDB和MyISAM，ARCHIVE提供压缩性能，领有高效地插入。
但不反对索引，所以查问性能较差。
反对insert、replace和select操作，不反对update和delete。

实用场景

数据归档

压缩比十分高，存储空间大略是innodb的10-15分之一，所以存储历史数据非常适合，因为不反对索引也不能缓存索引和数据，不适宜作为并发拜访表。

日志表

因为高压缩和疾速插入的特点。
但前提是不常常对该表进行查问。

PERFORMANCE_SCHEMA：

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

场景： DBA可能较明细得理解性能升高可能是因为哪些瓶颈。

Merge

Merge容许将一组应用MyISAM存储引擎的并且表构造雷同（即每张表的字段程序、字段名称、字段类型、索引定义的程序及其定义的形式必须雷同）的数据表合并为一个表，不便了数据的查问。

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

Federated

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

场景： dblink。

毛病：

1.对本地虚构表的构造批改，并不会批改近程表的构造

2.truncate 命令，会革除近程表数据

  1. drop命令只会删除虚构表，并不会删除近程表

4.不反对 alter table 命令

  1. 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

  1. 如果虚构虚构表中字段未建设索引，而实体表中为此字段建设了索引，此种状况下，性能也相当差。然而当给虚构表建设索引后，性能恢复正常。
  2. 相似 where name like "str%" limit 1 的查问，即便在 name 列上创立了索引，也会导致查问过慢，是因为federated引擎会将所有满足条件的记录读取到本，再进行 limit 解决。

Cluster/NDB

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

CAP实践。CAP实践(Brewer’s CAP Theorem) ，是说Consistency(一致性), Availability(可用性), Partition tolerance(散布) 三局部在零碎实现只可同时满足二点，没法三者兼顾。如果对"一致性"要求高，且必须要做到"分区"，那么就要就义可用性;而对大型网站，可用性与分区容忍性优先级要高于数据一致性，个别会尽量朝着 A、P 的方向设计，而后通过其它伎俩保障对于一致性的商务需要。

MyISAM

MySQL5.5版本之前默认数据库引擎，由晚期的ISAM所改进，提供ISAM所没有的索引和字段治理等大量性能。
实用于查问密集型，插入密集型。性能极佳，但却有一个毛病：不反对事务处理（transaction）。
因而，几年倒退后，MySQL引入InnoDB，以强化参照完整性与并发违规解决机制，取代了MyISAM。

每个MyISAM表，由存储在硬盘上的3个文件组成，每个文件都以表名称为文件主名，并搭配不同扩展名辨别文件类型：

  • .frm－－存储材料表定义，此文件非MyISAM引擎的一部分
  • .MYD－－寄存真正的材料
  • .MYI－－存储索引信息。

MyISAM应用表锁机制优化并发读写操作，但须要常常运行OPTIMIZE TABLE命令复原被更新机制所节约的空间，否则碎片也会随之减少，最终影响数据拜访性能。

MyISAM强调疾速读取操作，次要用于高并发select，这也是MySQL深受Web开发青睐起因：Web场景下大量操作都是读数据，所以大多数虚拟主机提供商和Internet平台提供商（Internet Presence Provider，IPP）只容许MyISAM格局。

MyISAM类型的表反对三种不同的存储构造：动态型、动静型、压缩型。

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

    • 长处:十分迅速，易缓存，呈现故障容易复原
    • 毛病:占用的空间通常比动静表多。动态表在数据存储时会依据列定义的宽度定义补足空格，然而在拜访的时候并不会失去这些空格，这些空格在返回给利用之前曾经去掉。同时须要留神：在某些状况下可能须要返回字段后的空格，而应用这种格局时前面到空格会被主动解决掉。

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

    • 长处:占用空间较少
    • 毛病:频繁更新删除记录会产生碎片，须要定期执行OPTIMIZE TABLE或myisamchk -r改善性能，并且呈现故障的时候复原绝对比拟艰难
  • 压缩表 由myisamchk工具创立，占据十分小空间，因为每条记录都是被独自压缩，所以只有十分小的拜访开销

InnoDB

  • MySQL5.5后的默认存储引擎

实用于更新密集型。

  • 零碎解体修复能力

InnoDB可借由事务记录日志（Transaction Log）恢复程序解体（crash），或非预期完结所造成的材料谬误；
而MyISAM遇到谬误，必须残缺扫描后能力重建索引，或修改未写入硬盘的谬误。InnoDB的修复工夫，大都固定，但MyISAM的修复工夫，与数据量成正比。绝对比拟，随数据量减少，InnoDB有更佳稳定性。

  • 缓存

MyISAM必须依附操作系统来治理读与写的缓存，而InnoDB则是有本人的读写缓存管理机制。InnoDB不会将被批改的数据页立刻交给操作系统（page cache），因而在某些状况下，InnoDB的数据拜访会比MyISAM更有效率。

  • 提供ACID事务、多版本并发MVCC管制的行锁。
  • 反对自增长列

自增长列的值不能为空，如果在应用的时候为空，则主动从现有值开始增值，如果有然而比当初的还大，则间接保留这个值。

  • 反对外键（foreign key）

外键所在的表称为子表而所依赖的表称为父表。

当操作齐全兼容ACID时，尽管InnoDB会主动合并多个连贯，但每次有事务产生时，仍至多须写入硬盘一次，因而对于某些硬盘或磁盘阵列，会造成每秒200次的事务处理下限。若心愿达到更高的性能且放弃事务的完整性，就必应用磁盘缓存与电池备援。当然InnoDB也提供数种对性能冲击较低的模式，但绝对的也会升高事务的完整性。
而MyISAM则无此问题，但这并非因为它比拟先进，这只是因为它不反对事务。

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

XtraDB为派生自InnoDB的强化版，由Percona开发，从MariaDB的10.0.9版起取代InnoDB成为默认的数据库引擎。

罕用的MyISAM与InnoDB引擎选型

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增长程序统一。

参考

  • https://zh.wikipedia.org/wiki...