Как вы выбираете движок базы данных MySQL

В частности, как вы выбираете между MyISAM и InnoDB, когда ни один из них не пропускает обязательную функцию (например, вам не нужны внешние ключи).

Всегда ли это сводится к тому, чтобы попробовать и измерять? Или существуют хорошие практические правила, касающиеся количества и частоты чтения или записи и других подобных мер? Влияет ли размер таблицы на типичный выбор?

Ответ заключается в том, что вы всегда должны измерять, желательно вашими данными и рабочей нагрузкой, если это вообще возможно.

Поскольку шаблоны доступа к данным могут сильно различаться в зависимости от приложения, трудно сказать и, по всей вероятности, невозможно определить «лучший» механизм хранения для всех рабочих нагрузок.

Тем не менее, в MySQL есть очень обнадеживающие события, которые посетили на прошлой неделе MySQLConf / Percona Performance Conf.

Некоторые из альтернативных механизмов хранения:

1. XtraDB (форк InnoDB)
2. Плагин InnoDB
3. PBXT
4. TokuDB

Кроме того, Percona, Google и т. Д. Предоставили исправления, которые очень помогают в производительности InnoDB. Лично я запускаю сборку OurDelta. Это хорошо работает для меня, и я рекомендую проверить сборки OurDelta и Percona.

Если это простая система хранения / отчетности, я использую MyISAM для ее сырой производительности.

Я бы использовал InnoDB, если бы меня беспокоило множественное одновременное обращение с большим количеством записей, чтобы воспользоваться преимуществами блокировки на уровне строк.

Существует множество тестов для различных баз данных MySQL. Есть достойный пример сравнения MyISAM, InnoDB и Falcon в блоге Percona MySQL Performance , смотрите здесь .

Между двумя вышеупомянутыми движками (MyISAM и InnoDB) следует учитывать еще одну проблему - подходы к блокировке. MyISAM выполняет блокировку таблиц, в то время как InnoDB выполняет блокировку строк. Есть множество вещей, которые нужно учитывать, а не только прямые показатели производительности.

Существуют функции, которые вы найдете очень полезными по эксплуатационным причинам, даже если ваше приложение не требует их абсолютно:

• InnoDB имеет MVCC, что означает, что вы можете делать неблокирующие последовательные резервные копии
• InnoDB имеет автоматическое восстановление, что означает отсутствие длительных операций REPAIR TABLE после нечистого отключения
• С InnoDB читатели никогда не блокируют авторов и наоборот, что означает (вообще говоря) больший параллелизм (хотя это не обязательно означает лучшую производительность в общем случае)
• InnoDB кластеризует свои строки на первичном ключе, что МОЖЕТ означать меньшее количество операций ввода-вывода для операций чтения, если первичный ключ был выбран достаточно хорошо.

Таким образом, несмотря на ограничения внешнего ключа, вы, вероятно, все равно захотите использовать InnoDB.

Конечно, это ServerFault, а не переполнение стека, поэтому правильный ответ:

• Вы всегда должны использовать движок, который выбрали разработчики приложений
• Если они не выбрали конкретный движок, они не очень серьезно относятся к использованию MySQL и, вероятно, не знают, как правильно его использовать.
• Вы не можете переключиться на другой движок, на котором тестировалось ваше приложение, это может привести к ошибкам.

Мой хостинг-провайдер посоветовал нам полностью избавиться от MyISAM и перейти на InnoDB, если это невозможно.

В нашем случае у нас было серьезное повреждение данных, которое начинало отображаться от нескольких раз до нескольких раз в день, всегда требуя REPAIR TABLE и связанных команд, которые занимали много времени на больших таблицах.

Как только мы преобразовали (или: были преобразованы) в InnoDB, проблемы немедленно исчезли. Недостатки / предостережения у нас были:

• Невозможно преобразовать таблицы с индексом FULLTEXT (эта проблема со временем исчезла сама по себе; она была заменена решением на основе Solr / Lucene, которое в любом случае имеет гораздо лучшее качество)
• Большие таблицы с миллионами строк, которые часто требуют COUNT (*), были очень медленными, мы также не смогли их переключить.

Но обратите внимание: это все специфично для нашей среды и т. Д., Поэтому может не применяться.