还可以看看MySQL本身的一些替代品:

玛丽亚数据库

http://mariadb.org/

MariaDB是一个数据库服务器，为MySQL提供了直接替换功能。MariaDB是由MySQL的一些原始作者在更广泛的免费和开源软件开发人员社区的帮助下构建的。除了MySQL的核心功能之外，MariaDB还提供了一组丰富的功能增强，包括备用存储引擎、服务器优化和补丁。

Percona服务器

https://launchpad.net/percona-server

一个增强型的MySQL替代品，具有更好的性能、改进的诊断和新特性。

每个应用程序在使用数据库时都有自己的性能配置文件，并且可能会随着时间的推移而改变。

你能做的最好的事情就是测试你的选择。在MyISAM和InnoDB之间切换是很简单的，所以加载一些测试数据并在你的站点上启动jmeter，看看会发生什么。

有点偏离主题，但为了文档的目的和完整性，我想添加以下内容。

一般来说，使用InnoDB会使应用程序变得不那么复杂，可能也更没有bug。因为可以将所有引用完整性(外键约束)放入数据模型中，所以不需要像使用MyISAM时那样多的应用程序代码。

Every time you insert, delete or replace a record, you will HAVE to check and maintain the relationships. E.g. if you delete a parent, all children should be deleted too. For instance, even in a simple blogging system, if you delete a blogposting record, you will have to delete the comment records, the likes, etc. In InnoDB this is done automatically by the database engine (if you specified the contraints in the model) and requires no application code. In MyISAM this will have to be coded into the application, which is very difficult in web-servers. Web-servers are by nature very concurrent / parallel and because these actions should be atomical and MyISAM supports no real transactions, using MyISAM for web-servers is risky / error-prone.

而且在大多数情况下，InnoDB会表现得更好，原因有很多，其中一个原因是它能够使用记录级锁而不是表级锁。不仅在写比读更频繁的情况下，在大型数据集上有复杂连接的情况下也是如此。我们注意到，对于非常大的连接(需要几分钟)，使用InnoDB表比MyISAM表性能提高了3倍。

我想说的是，在使用MySQL时，InnoDB(使用3NF数据模型，具有引用完整性)应该是默认的选择。MyISAM只能在非常具体的情况下使用。它很可能会执行更少，导致应用程序更大，bug更多。

话虽如此。数据模型是一门很少在网页设计师/程序员中发现的艺术。无意冒犯，但这确实解释了MyISAM被如此广泛使用的原因。

底线:如果你离线工作，选择大量的数据，MyISAM可能会给你更好的(好得多)速度。

在某些情况下，MyISAM比InnoDB的效率要高得多:离线操作大型数据转储时(因为表锁)。

示例:我正在从NOAA转换一个csv文件(15M条记录)，它使用VARCHAR字段作为键。InnoDB的运行时间很长，即使有大量的内存可用。

这是CSV的一个例子(第一个和第三个字段是键)。

USC00178998,20130101,TMAX,-22,,,7,0700
USC00178998,20130101,TMIN,-117,,,7,0700
USC00178998,20130101,TOBS,-28,,,7,0700
USC00178998,20130101,PRCP,0,T,,7,0700
USC00178998,20130101,SNOW,0,T,,7,

因为我需要做的是运行观察到的天气现象的批量离线更新，我使用MyISAM表接收数据，并在键上运行join，这样我就可以清理传入的文件，并将VARCHAR字段替换为INT键(与原始VARCHAR值存储的外部表相关)。

对于一个有更多写和读的负载，你将受益于InnoDB。因为InnoDB提供的是行锁而不是表锁，所以你的select可以是并发的，不仅仅是彼此之间的select，还有许多insert。但是，除非你打算使用SQL事务，否则将InnoDB提交刷新设置为2 (innodb_flush_log_at_trx_commit)。这将为您提供大量原始性能，否则将表从MyISAM转移到InnoDB时会损失这些性能。

Also, consider adding replication. This gives you some read scaling and since you stated your reads don't have to be up-to-date, you can let the replication fall behind a little. Just be sure that it can catch up under anything but the heaviest traffic or it will always be behind and will never catch up. If you go this way, however, I strongly recommend you isolate reading from the slaves and replication lag management to your database handler. It is so much simpler if the application code does not know about this.

最后，要注意不同的表负载。您不会在所有表上都有相同的读/写比率。一些接近100%读取的小表可以负担得起MyISAM。同样地，如果你有一些接近100%写的表，你可能会受益于INSERT DELAYED，但这只在MyISAM中支持(对于InnoDB表，DELAYED子句会被忽略)。

但基准是肯定的。

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

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

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

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