我的网站偶尔会有相当可预测的流量突发，吞吐量比正常情况下增加100倍。例如，我们将在电视节目中出现，我预计在演出后的一小时内，我的流量将超过正常水平的100倍。
我的理解是MySQL（InnoDB）通常将我的数据保存在许多不同的地方：
考虑到我在EC2节点上并且大部分内容都经过相同的网络管道（文件系统是网络连接的），这太“持久”了。此外，驱动器速度很慢。这些数据价值不高，我宁愿少花几分钟的数据丢失，而不是在人群到来时很可能发生中断。
在这些流量突发期间，如果我能负担得起，我想完成所有I / O 。我想尽可能多地保留在RAM中（与一小时内触摸的数据大小相比，我有相当大的RAM空间）。如果缓冲区变得稀缺，或者I / O通道没有太多过载，那么我确定，我希望将事件转到commitlog或二进制日志以发送给slave。如果且仅当I / O通道没有过载时，我想回写实际的表。
换句话说，我希望MySQL / InnoDB使用“回写”缓存算法而不是“直写”缓存算法。我可以说服它这样做吗？
如果无法做到这一点，我对一般的MySQL写性能优化技巧感兴趣。大多数文档都是关于优化读取性能的，但是当我收到大量用户时，我正在为所有用户创建帐户，因此这是一个写入繁重的工作量。
答案 0 :(得分：3)
如果您有额外的风险，这两项更改将大大提高您的写作效果。
设置innodb_flush_log_at_trx_commit = 0
设置sync_binlog = 0
此外，您的缓冲池大小应该是服务器内存的70-80％左右。增加日志文件大小和日志缓冲区大小也有一定程度的帮助。
答案 1 :(得分：1)
在很大程度上，InnoDB已经做到了这一点。
当您提交数据时，会将其写入日志文件以进行恢复，但对表空间（数据）的修改仅在以后作为后台进程（“检查点”）进行。
您可以在较新的InnoDB版本（innodb_io_capacity）中指定要为该后台进程投入多少IOPS（http://en.wikipedia.org/wiki/IOPS），并且只要将innodb_log_file_size设置得足够大，InnoDB就会落后一段时间，稍后再回来。
如果InnoDB在后台工作方面落后太多，当你到达日志文件的末尾时，它会在性能上产生急剧的下降，并且必须循环回来。请参阅这些基准测试中的“无”行： http://www.mysqlperformanceblog.com/2009/09/15/which-adaptive-should-we-use/