MyISAM 引擎
一、MyISAM 是 MySQL 默认的引擎，它的设计目标是快速读取。
MyISAM 引擎使用 B+ 树作为索引结构，使用的是非聚集索引，所以叶子节点的 data 域存放的是数据记录的地址。下图是MyISAM索引的原理图： 
这里设表一共有三列，假设我们以 Col1 为主键，则上图是一个MyISAM 表的主索引（Primary key）示意。可以看出 MyISAM 的索引文件仅仅保存数据记录的地址。在 MyISAM 中，主索引和辅助索引（Secondary key）在结构上没有任何区别，只是主索引要求key是唯一的，而辅助索引的key可以重复。如果我们在Col2上建立一个辅助索引，则此索引的结构如下图所示：
同样也是一颗 B+树，data 域保存数据记录的地址。因此，MyISAM 中索引检索的算法为首先按照 B+树搜索算法搜索索引，如果指定的 Key 存在，则取出其 data 域的值，然后以 data 域的值为地址，读取相应数据记录。
二、MyISAM 引擎优点：
1. 高性能读取；
2. 因为它保存了表的行数，当使用COUNT统计时不会扫描全表；
三、MyISAM 引擎缺点
1. 不支持数据库事务（InnoDB 引擎支持数据库事务，有提交（commit），回滚（rollback）等命令用于数据库的事务）；
2. 不支持行级锁和外键（InnoDB 引擎支持行级锁和外健，外健就是在 B 表中存在一列，要求这一列是表 A 中的主键）；
3. INSERT 和UPDATE 操作需要锁定整个表（没有行级锁，只有表级锁）；
4. 不支持故障恢复（也可以理解为和数据库事务相关的）；
MyISAM 引擎适用场景
1. 不需要事务的操作；
2. 插入、更新少，读取频繁；
3. 频繁的统计计算。
InnoDB存储引擎
一、InnoDB是一个支持事务型的存储引擎，设计目标是处理大数量数据时提供高性能的服务，它在运行时会在内存中建立缓冲池，用于缓冲数据和索引，使用聚簇索引。
InnoDB 使用 B+树作为索引结构，使用聚簇索引，但具体实现方式却与 MyISAM 截然不同。
第一个重大区别是 InnoDB 的数据文件本身就是索引文件，也就是说 B+ 数的叶子结点存储的是具体的索引文件（完整的数据记录），而不是 MyISAM 中非聚簇索引中的叶子结点存储的索引文件的地址。这个索引的 key 是数据表的主键，因此 InnoDB 表数据文件本身就是主索引。
因为 InnoDB 的数据文件本身要按主键聚集，所以 InnoDB 要求表必须有主键（MyISAM可以没有），如果没有显式指定，则 MySQL 系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则 MySQL 自动为InnoDB 表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。
第二个与 MyISAM 索引的不同是 InnoDB 的辅助索引 data 域存储相应记录主键（key）的值而不是地址。换句话说，InnoDB 的所有辅助索引都引用主键作为 data 域。例如，下图为定义在 Col3 上的一个辅助索引：
这里以英文字符的 ASCII 码作为比较准则。聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。
了解不同存储引擎的索引实现方式对于正确使用和优化索引都非常有帮助，例如知道了 InnoDB 的索引实现后，就很容易明白为什么不建议使用过长的字段作为主键，因为所有辅助索引的叶子结点存储的值都是引用主索引，过长的主索引会令辅助索引变得过大。再例如，用非单调的字段作为主键在 InnoDB中 不是个好主意，因为 InnoDB数据文件本身是一颗 B+树，非单调的主键会造成在插入新记录时数据文件为了维持 B+ 树的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。
二、InnoDB引擎优点
1.支持事务处理、ACID 事务特性；
2.实现了 SQL 标准的四种隔离级别；
3.支持行级锁和外键约束；
4.可以利用事务日志进行数据恢复。
三、InnoDB 引擎缺点
不支持 FULLTEXT 类型的索引，因为它没有保存表的行数，当使用 COUNT 统计时会扫描全表。
InnoDB 引擎适用场景
1.需要事务的操作；
2.更新数据需要使用行级锁；
3.大数据量读写；
4.大型互联网应用。