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…