MySQL常见的存储引擎

InnoDB存储引擎的特点

事务型存储引擎支持ACID

InnoDB存储引擎跟其它存储引擎像相比，最重要的是它是有一款事务型的存储引擎，其完全支持事务的原子性、一致性、隔离性和持久性这些特点，换句话说如果在我们业务场景中，需要把使用的数据用事务的话，最好的选择就是使用InnoDB存储引擎，并且需要在事务支持的场景中，一定不要混合使用事务型存储引擎和非事务型存储引擎。因为混合使用的话，在使用中一旦事务需要回滚，那么对于非事务型的存储引擎呢是无法回滚的，这样就破坏了事务的一致性要求，同时也破坏了事务完整性

数据按主键聚集存储

InnoDB中的数据在逻辑上是按照表中主键的顺序存储的，也就是说InnoDB中的主键是一种距离索引的主键。我们在选择使用什么样的列做为表中主键的时候，就要特别注意了，MYISAM使用的是堆方式进行存储，在具有距离索引的主键中，每一个非主键的叶子节点所指向的都是数据行中的主键，而不是数据行的物理存储位置，因此主键的大小就直接影响到了索引查找数据的性能。
另一方面，由于数据是按照逻辑主键的顺序排列进行存储，如果键的顺序经常变化，一定会造成数据的迁移，这样也会带来IO性能上的一些损耗。所以，一般来讲我们使用InnoDB做为存储引擎的表，都是建议使用一个自增Id来做为表的主键的，那么从这一点上来看，之前对表进行逻辑设计时，选择的业务主键并不适合做为InnoDB里的主键来使用，但是我们现在又需要使用Inn’o’DB存储引擎来存储我们的业务数据，这时候就要为每个表再加一个自增Id列来做为表的数据库主键，而之前所选择的业务主键必须再上面建立一个唯一索引，这样也可以同样保证其数据时唯一的

支持行级锁及MVCC

在进行数据读写操作时，可以对需要读取的数据行来加锁，而不会像MYISAM那样在整个表上枷锁，这无疑能大大加大我们存储引擎的数据并发处理能力
另外，Inn’o’DB还支持MVCC，也就是这个多版本的并发控制，可以进一步避免这个读写操作的互相阻塞
所以，Inn’o’DB非常适合那种高并发的读写混合的场景来使用

支持Btree和自适应Hash索引

所谓自适应Hash索引，就是由存储引擎对数据的统计信息在内存中自动建立的hash索引，这种索引只能用于等值查找，并且只能由InnoDb内部来进行维护，不需要DBA来进行过多的干预

支持全文和空间索引

MySQL5.6之后，InnoDB支持了全文索引。MySQL5.7之后版本中，InnoDB又支持了对空间索引。在MySQL5.7之前如果我们想使用MySQL的全文索引和空间索引呢，就必须使用MYISAM存储引擎，因为那时候只有MYISAM支持这两种索引。在MySQL5.7后，如果你想使用全文和空间索引就可以使用InnoDB做存储引擎了，这也就是说，在没有什么特殊需要的话，就可以完全使用Inn’o’DB来做存储引擎了。