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增长顺序一致。
参考
