我在表格中简要地讨论了这个问题，这样你就可以决定是使用InnoDB还是MyISAM。

下面是在哪种情况下应该使用哪种db存储引擎的一个小概述:

                                                 MyISAM   InnoDB
----------------------------------------------------------------
Required full-text search                        Yes      5.6.4
----------------------------------------------------------------
Require transactions                                      Yes
----------------------------------------------------------------
Frequent select queries                          Yes      
----------------------------------------------------------------
Frequent insert, update, delete                           Yes
----------------------------------------------------------------
Row locking (multi processing on single table)            Yes
----------------------------------------------------------------
Relational base design                                    Yes

总结

在几乎所有的情况下，InnoDB都是最好的选择 但是，经常阅读，几乎不写，使用MyISAM 全文搜索MySQL <= 5.5，使用MyISAM

几乎每次我开始一个新项目时，我都会问同样的问题，看看我是否能想出新的答案。

它最终归结为——我使用最新版本的MySQL并运行测试。

我有表，我想做键/值查找…就这些。我需要得到一个哈希键的值(0-512字节)。这个数据库上没有很多事务。表偶尔会更新(整个表)，但是没有事务。

所以我们这里讨论的不是一个复杂的系统，我们讨论的是一个简单的查找，..以及如何(除了使表RAM常驻)优化性能。

我也在其他数据库(即NoSQL)上做测试，看看是否有任何地方我可以获得优势。我所发现的最大优势是键映射，但就查找而言，MyISAM目前是所有优势中的佼佼者。

虽然，我不会执行与MyISAM表的金融交易，但对于简单的查找，你应该测试它。通常是2倍到5倍的查询/秒。

试试吧，我欢迎辩论。

我认为这是一篇很好的文章，解释了两者之间的区别，以及什么时候应该使用其中一种: http://tag1consulting.com/MySQL_Engines_MyISAM_vs_InnoDB

我不是数据库专家，也不是凭经验说的。然而:

MyISAM表使用表级锁定。根据您的流量估计，您每秒有接近200个写入操作。有了MyISAM，在任何时候只有其中一项可以进行。您必须确保您的硬件能够跟上这些事务，以避免超时，即单个查询的时间不能超过5毫秒。

这就意味着你需要一个支持行级锁的存储引擎，比如InnoDB。

另一方面，编写几个简单的脚本来模拟每个存储引擎的负载，然后比较结果应该是相当简单的。

如果它是70%的插入和30%的读取，那么它更像是在InnoDB端。

人们经常谈论性能、读写、外键等等，但在我看来，存储引擎还有一个必须具备的特性:原子更新。

试试这个:

Issue an UPDATE against your MyISAM table that takes 5 seconds. While the UPDATE is in progress, say 2.5 seconds in, hit Ctrl-C to interrupt it. Observe the effects on the table. How many rows were updated? How many were not updated? Is the table even readable, or was it corrupted when you hit Ctrl-C? Try the same experiment with UPDATE against an InnoDB table, interrupting the query in progress. Observe the InnoDB table. Zero rows were updated. InnoDB has assured you have atomic updates, and if the full update could not be committed, it rolls back the whole change. Also, the table is not corrupt. This works even if you use killall -9 mysqld to simulate a crash.

性能当然是可取的，但不丢失数据更重要。