我正在从事一个涉及大量数据库写入的项目(70%的插入和30%的读取)。这个比率还包括我认为是一个读一个写的更新。读取可能是脏的(例如，在读取时我不需要100%准确的信息)。 该任务每小时将处理超过100万个数据库事务。
我在网上读了一堆关于MyISAM和InnoDB之间区别的东西，对于我将用于这个任务的特定数据库/表来说，MyISAM似乎是显而易见的选择。从我看来，InnoDB在需要事务时是很好的，因为它支持行级锁。
有人有这种负载(或更高)的经验吗?MyISAM是正确的选择吗?
当前回答
对于一个有更多写和读的负载，你将受益于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有锁争用，它在大多数情况下仍然比InnoDb快，因为它使用了快速的锁获取方案。我尝试了几次Innodb，总是因为这样或那样的原因回到MyIsam。此外，InnoDB在巨大的写负载下会非常消耗CPU。
人们经常谈论性能、读写、外键等等，但在我看来，存储引擎还有一个必须具备的特性:原子更新。
试试这个:
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.
性能当然是可取的，但不丢失数据更重要。
这个问题和大部分答案都已经过时了。
是的，MyISAM比InnoDB快是无稽之谈。注意问题的日期:2008年;现在已经过去了近十年。从那时起，InnoDB在性能上取得了显著的进步。
戏剧性的图表是MyISAM获胜的一种情况:没有where子句的COUNT(*)。但这真的是你花时间做的事情吗?
如果你运行并发测试，InnoDB很可能会赢，即使是对MEMORY。
如果在对select进行基准测试时执行任何写入操作，MyISAM和MEMORY可能会因为表级锁定而丢失。
事实上，Oracle非常确定InnoDB更好，以至于他们几乎从8.0中删除了MyISAM。
这个问题写于5.1的早期。从那时起，这些主要版本被标记为“一般可用性”:
2010: 5.5(。12月8日) 2013: 5.6(。2月10日) 2015年:5.7(。10月9日) 2018年:8.0(。四月十一日)
底线:不要使用MyISAM
如果它是70%的插入和30%的读取，那么它更像是在InnoDB端。
myisam对于这种类型的工作负载(高并发写入)是一个NOGO，我对innodb没有那么多的经验(测试了3次，发现每次性能都很糟糕，但自从上次测试以来已经有一段时间了) 如果你没有被强迫运行mysql，可以考虑尝试postgres，因为它处理并发写要更好
