Уменьшите длительность в MySQL для производительности

Мой сайт иногда имеет довольно предсказуемые пакеты трафика, которые увеличивают пропускную способность в 100 раз более нормальным, чем. Например, мы собираемся быть известными в телевизионном шоу, и я ожидаю в час после шоу я получу больше чем в 100 раз больше трафика, чем нормальный.

Мое понимание - то, что MySQL (InnoDB) обычно сохраняет мои данные в наборе различных мест:

• Буферы RAM
• commitlog
• двоичный журнал
• фактические таблицы
• Все вышеупомянутые места на моем ведомом устройстве DB

Это - слишком много "длительности", учитывая, что я нахожусь на узле EC2, и большая часть материала идет через тот же сетевой канал (файловые системы являются присоединенной сетью). Плюс диски являются просто медленными. Данные не являются высоким значением, и я рискнул бы нескольких минут потери данных, а не имел бы высокую вероятность отключения электричества, когда толпа прибывает.

Во время этих всплесков трафика я хотел бы сделать, все изо что ввод-вывод, только если я могу предоставить его. Я хотел бы просто сохранить как можно больше в RAM (у меня есть справедливый блок RAM по сравнению с размером данных, который был бы затронут более чем час). Если бы буферы становятся недостаточными, или канал ввода-вывода не слишком перегружается, то уверенный, я хотел бы вещи перейти к commitlog или двоичному журналу, который будет отправлен в ведомое устройство. Если, и только если, канал ввода-вывода не перегружается, я хотел бы записать обратно к фактическим таблицам.

Другими словами, я хотел бы, чтобы MySQL/InnoDB использовал "записывать обратно" алгоритм кэширования, а не "запись через" алгоритм кэширования. Я могу убедить это делать это?

Если это не возможно, я интересуюсь общими подсказками по оптимизации производительности записи MySQL. Большинство документов об оптимизации производительности чтения, но когда я получаю толпу пользователей, я создаю счета на всех них, таким образом, это - тяжелая записью рабочая нагрузка.