1.FEDERATED存储引擎
在阿粉之前翻看书籍的时候就看到过这个，说这个引擎不是存放数据的引擎，而是一个指向远程MySQL数据库服务器的，那是什么意思呢，其实一句大白话：“我这里不存表结构文件和数据文件，我是在远程端存的”，这时候就有了个比较有意思的地方，如下图：
就像图上说的，FEDERATED存储引擎分成了2部分，一部分是本地服务，另外一部分就是远程服务，那么如果在你切换到这个引擎的时候，他在执行CRUD的时候，就会把执行操作的命令发到远程服务器，然后执行完了之后，在发回本地，然后从本地服务器中返回匹配的行即可。
在这里，阿粉不去着重的讲这个，因为重点是我们最常使用的那个，大家肯定都知道，那就是InnoDB存储引擎。
2.InnoDB存储引擎
InnoDB存储引擎这个一般也是大家在面试中经常的能和面试官侃侃而谈的一个，因为它是默认的数据库存储引擎。注意，这个默认是从MySQL的5.5.8开始的
特点比较多，下面就开始分析一下都有哪些特点吧。
- 支持事务。默认的事务隔离级别为可重复，这个我们经常用，所以肯定也都知道。
- 支持外键，这个外键大家肯定也都清楚，有利有弊，毕竟外键的作用在那里放着(利：增加可读性，若出现宕机，最大限度的保证数据的一致性和完整性，弊：降低了表的查询速度，如果数据了过大，那么你插入数据库数据的时长可能是不增加外键的十倍)
- 行锁设计，这样可以支持更高的并发，这也是为什么有时候面试官说你们上ES有点大材小用，因为MySQL自己也能处理那么多。
- 使用多版本并发控制（MVCC）来获得高并发性，并且实现了SQL标准的4种隔离级别，默认为REPEATABLE READ级别。
- 使用一种被称为next-key locking(有人称它为间隙锁)的策略来避免幻读（phantom）现象的产生
- 数据存储采用了聚集（clustered）的方式，每张表的存储都是按主键的顺序进行存放。
- InnoDB的索引结构和MySQL其他的存储引擎不同，聚簇索引对主键查询性能非常高，这时候就得有个限制要求，如果表上的索引较多，主键就尽可能的小。
- InnoDB通过一些机制和工具都支持真正的热备份，也就是在线热备份。
- 数据存储在表空间(tablespace)中，这个表空间实际上是由InnoDB管理的一个黑盒，由一系列的文件组成。
2.1InnoDB的体系架构
我们从上面的图中就能看到，InnoDB存储引擎有许多的内存块，可以认为这些内存块其实就相当于是一个大的内存池，就是线程池是类似的那种，
既然图中我们看到了后台的线程，那么我们也要说说这个后台线程是个什么？
InnoDB存储引擎是多线程的模型，因此其后台有多个不同的后台线程，负责处理不同的任务。
而这个后台线程也是分两个部分的，一个是核心线程，一个是IO线程。
- 核心线程Master Thread
- IO线程 IO Thread
- 净化线程Purge Thread
- 清理线程Page Cleaner Thread
核心线程
核心线程的作用就是将缓冲池中的数据异步的刷新到磁盘上，来保证数据的一致性。
IO线程
IO线程则很简单，主要就是用来IO请求的回调处理。
净化线程
主要作用就是事务提交之后回收已经使用并分配的undo页
清理线程
他的作用是将之前版本中脏页的刷新操作都放入到单独的线程中来完成。
如果阿粉当时面试的时候能够把这些内容给面试官说上，相信工资肯定还能再多来点。
3.Memory 存储引擎
Memory 存储引擎实际上就是将表中的数据存放在内存中，如果数据库重启或发生崩溃，表中的数据都将消失。也就是说，如果你们的数据存储在Memory 存储引擎中，如果机房不慎掉电，那完了，之前存在里面的东西都没了，就和你用了个 rm -rf效果一样，不过一个是被动的，一个是主动的。
这种用的比较少，阿粉就不再多给大家介绍了，就说说它的特点得了，毕竟一个关机，直接就没了。
- 不支持TEXT和BLOB类型，对于字符串类型的数据，只支持固定长度的行，VARCHAR会被自动存储为CHAR类型；
- 速度非常快，只支持表锁，并发性能较差，并且不支持TEXT和BLOB列类型
- 服务器一但出现宕机，所有数据全部消失
- 存储变长字段（varchar）时是按照定常字段（char）的方式进行的，因此会浪费内存
4.MyISAM存储引擎
这个引擎特点非常明显，不支持事务，但是支持全文检索，要面向一些OLAP(联机分析处理)数据库应用.
5.BLACKHOLE存储引擎
这个引擎就像他的名字一样，肉包子打狗，有去无回，它的用途也比较简单
- SQL 文件语法的验证
- 用来查找与存储引擎自身不相关的性能瓶颈
6.CSV存储引擎
CSV 存储引擎实际上操作的就是一个标准的CSV 文件，而且他的特点就是不支持索引，也就说，不支持索引，那么效率必然会很低，这个相信很多人都不会选择去使用它。
针对这些引擎，阿粉就说，既然都了解了这么多的内容了，那肯定不能在继续说我们的SQL语句优化了，当你在面试的时候，就要有针对性的了。
假如说面试的时候，面试官问你：现在有一个功能，测试那边反馈过来的信息是，这个功能的响应时间超出了预期的值，你都从哪些方面入手来处理这个问题。
这个问题看似不是很难，但是可以根据这个问题延伸出很多很多的问题。
问题一：如果你说从SQL语句优化，入手，那么势必要去检查索引，而面试官下一个问题可能就是，为什么加了索引，速度就会变快。
问题二：如果你说服务器的配置，那么面试官可能心里就想，为了一个功能上的反馈，你让我去给服务器增加配置，代价太大。
如果你对索引还没有了解到很深层面的时候，这个时候你就可以把SQL语句优化，和看数据库该表的引擎是否可以进行修改，如果可以，那么你就可以开始把这些关于SQL引擎的优势往自己的方向走了。
文献参考
《高性能MySQL》
《MySQL技术内幕》
