喜欢深挖的，可以去看看；
InnerDB：
事务型存储引擎，作为 MySQL 默认的存储引擎，应该说是在 MySQL 4.0 + 以后的版本推出来的。
他被设计用来处理大量的短期事务，短期事务大部分情况是正常提交的，很少会被回滚。
InnoDB的性能和自动崩溃恢复特性，使得他在非事务型存储的需求中也很流行，
除非有非常特别的原因需要使用其他的存储引擎，否则应该有限考虑InnoDB引擎。
InnoDB 的数据存储在表空间，表空间由InnoDB管理的一个黑盒子，由一系列的数据文件组成。
InnoDB 可以将每个表的数据和索引存放在单独的文件中。
InnoDB 也可以使用裸设备作为表空间的存储介质，但现在的文件系统是的裸设备不再是必要的选择。
InnoDB 采用 MVCC 支持高并发，并且实现了四个标准的隔离级别。
其默认级别是 REPEATABLE READ，并且通过间隙锁策略防止幻读的出现，
间隙锁是的InnoDB不仅仅锁定查询涉及的行，还会对索引中的间隙进行锁定，以防止幻行的插入。
InnoDB内部做了很多就花，包含从磁盘读取数据时采用的可预测性预读，
能够自动在内存中创建hash索引以加速读操作的自适应哈希索引，以及能够加速插入操作的插入缓存等。
作为事务型的存储引擎，InnoDB通过一些机制和工具支持真正的热备份，
Oracle 提供的MySql Enterprise Backup , Percona提供的开源的XtraBackup都可以做到这一点。
MySQL 的其他存储引擎不支持热备份，要获取一致性视图需要停止对所有表的写入，而在读写混合场景中，停止写入可能意味着停止读取。
MyISAM：
MyISAM 的锁级别，不像 InnerDB 支持到行级锁，它只支持到表级锁，同时 MyISAM 不支持事务，
没有了解过的同学，不要在你执行了 Back 操作后一脸懵逼的问，明明回滚了为什么数据还是被提交了。
很早看过一篇关于 MySQL 存储引擎的如何做选择的文章，笔者对 InnerDB 和 MyISAM 分别做了读写的性能对比，
毫无疑问，MyISAM 的读写操作是高于 InnerDB 的，但是 MyISAM 也有很多的弊端，所以在选择时，应根据业务的需要作出决策，
否则出了问题，也会是坑了队友。如一些日志表，就可以直接选择 MyISAM。
MyISAM 不支持热备份，但是可以手工或者自动执行检查和修复操作，但这里说的修复和事务恢复以及崩溃恢复是不同的概念。执
行表的修复可能导致一些数据丢失，而且 修复操作是非常慢的。
五、如何选择合适的存储引擎
总结一句话：除非需要用到某些 InnerDB 不具备的特性，并且没有其他办法可以代替，否则应该优先选择 InnerDB 存储引擎；
// 不是非常特殊的情况，不要混合使用多种存储引擎；
不要轻易相信“MyISAM 比 InnerDB 快”之类的经验之谈，这个结论往往不是绝对的。
在很多我们已知的场景中，InnerDB 的速度都可以让 MyISAM 望尘莫及了，尤其是使用到聚簇索引，
或者需要访问的数据可以放入内存应用。
