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