1、InnoDB支持事务，MyISAM不支持，也就是说MyISAM不支持事务回滚操作，这个功能可能是致命的

2、InnoDB支持行锁，MyISAM只支持表锁，不过InnoDB的行锁是建立在索引之上的，也就是说如果索引未命中，那么此次操作还是会降级到表锁。如uid为索引

update t_user set age=10 where uid=1;             命中索引，行锁。

update t_user set age=10 where uid != 1;           未命中索引，表锁。

3、InnoDB表是基于聚簇索引建立的，采用B+树，MyISAM是基于非聚簇索引，索引数据结构也是B+树

聚簇索引：它并不是一种单独的索引类型，而是一种数据存储方式。聚簇索引是依托主键而建立的，这种存储方式将索引值与数据行全部存储到同一个结构中。

如果没有主键，InnoDB会选择一个唯一的非空索引代替，如果没有符合条件的索引，InnoDB会隐式的创建一个主键来作为聚簇索引。InnoDB中，其非聚簇索引，又叫辅助索引或者二级索引，他们是将数据行地址(这里更正一下，二级索引中存放的并不是指向行的指针，而是行的主键值！)存到B+树的叶子结点中，也就是说，想通过二级索引查找行数据，存储引擎需要先找到二级索引的叶子结点对应的主键值，然后根据这个值去聚簇索引中查找到相应的数据行。这里做了重复的工作，因此至少做两次B+tree查找(至少，是因为可能有的数据更新后无法存储在原来的位置，这会导致表中出现行的碎片化或者在原位置留下一个指向新位置的指针，因此一次非聚簇索引未必能找到目的主键值)。对于InnoDB来说，自适应哈希索引能够减少这样的重复工作。

因此，聚簇索引对于IO密集型的系统来说至关重要，可以大大提高其性能。但如果系统将数据全部存放在内存中，聚簇索引便没什么优势了。但是，聚簇索引也有一定的弊端，比如更新局促索引列的代价太高，整行数据都得跟着索引移到新的位置，还有页分裂问题等。

对于MyISAM存储引擎，包含以下三种格式的文件：

.frm      是描述表结构的文件

.MYD   是表的数据文件

.MYI     是表数据文件中任何索引的数据树

对于InnoDB，索引和数据都在同一个文件内，.IDB

4、InnoDB是不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快

5、InnoDB版本5.7之后才开始支持全文索引，而MyISAM一直支持全文索引

6、MyISAM是支持压缩的，压缩后的表传输、查询速率都大大提高，不过压缩状态下的表是不可以修改的，只有解压后才可修改

7、InnoDB支持外键而MyISAM不支持，也就是说，如果将一个表由InnoDB转成MyISAM然后再转回来，外键会消失

8、InnoDB表必须有主键(用户没有指定的话会自己找或生成一个隐式主键)，而Myisam可以没有

那么二者如何选择呢？

如果需要事务和事务回滚，InnoDB！

如果读远多于写，MyISAM！

如果你还是没主意，那就InnoDB吧，毕竟它是目前主推(默认)的内存引擎

最后，这里提一下InnoDB引擎的四大特性(想要深入研究的同学可以看这位博主的链接)：插入缓冲(insert buffer),二次写(double write),自适应哈希索引(ahi),预读(read ahead)