记得一年多前在为咱们的产品选择MySQL的存储引擎时——InnoDB和MyISAM之间，费了好大的功夫，从网络和一些书籍中收集了不少资料来论证，最终咱们以究竟是读多写少仍是写多读少这个广泛观点当作决定条件选择了InnoDB。前些日子在阅读了《高性能MySQL》(第三版，这一版由淘宝的DBA翻译，我我的感受质量很是好）以后，书中对存储引擎的选择有着更权威更系统的回答，下面我就循着书籍来给你们总结一下咱们耳熟能详的两个存储引擎InnoDB和MyISAM在产品中如何选择。安全
先看书中这么几句话：“大部分状况下，InnoDB都是正确的选择 ； 除非要用到某些InnoDB不具有的特性，而且没有其余办法能够替代，不然都应该优先选择InnoDB引擎”，好比这个例子，若是要用到全文索引，建议先考虑InnoDB加上Sphinx的组合，而不是使用支持全文索引的MyISAM。网络
InnoDB的一些特性ide
事务支持：若是应用须要事务支持，那么InnoDB是目前最稳定而且是通过验证的选择；性能
备份：若是须要在线热备份，选择InnoDB就是基本的要求；翻译
崩溃恢复：相对而言，MyISAM崩溃后发生损坏的几率比InnoDB要高不少，并且恢复速度也慢。所以，即便不须要事务支持，不少人也会选择InnoDB。InnoDB还支持真正的热备份；设计
锁粒度：InnoDB支持的是行级锁；日志
MyISAM的一些特性索引
锁粒度：表级锁，读取时会对操做表加共享锁，写入时则加排它锁；事务
修复：支持手工或者自动执行检查的修复操做。可是修复可能会致使一些数据丢失，并且修复操做很慢；get
索引特性：支持全文索引；
延迟更新索引键：提高了写入性能下降了安全性；
MyISAM引擎设计简单，数据以紧密格式存储，因此在某些场景下性能很好；
前面我说的之前选择MySQL到底是采用的InnoDB仍是MyISAM存储引擎主要看应用场景是“读多写少仍是仍是写多读少”，若是是前者就采用MyISAM，后者就采用InnoDB。书中也有建议“对于只读或者大部分状况下只读的表，若是不介意MyISAM的崩溃恢复问题，选用它是合适的。可是仍然给咱们提了个醒：MyISAM引擎在一开始可能没有任何问题，但随着应用压力的上升，则可能迅速恶化。各类锁争用、崩溃后的数据丢失等问题都会随之而来。
从上面的分析和建议来看，之于InnoDB引擎，仿佛MyISAM缺点多多。可是其存在就有其意义，对于日志型应用，CD-ROM的应用（MyISAM的压缩表）...选用MyISAM是很是适合的。
以上就是我结合《高性能MySQL》这本书籍对两个经常使用存储引擎选择的总结，书中全篇都在讲如何合适，更高效的使用MySQL，建议感兴趣的朋友进行全面阅读，为本身的应用搭建起高效健壮的数据中心。