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

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

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

Источник

5 ответов

Решение

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

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

Тем не менее, есть очень обнадеживающие события в пространстве 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(*), были очень медленными, мы также не смогли их переключить.

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

Источник
Другие вопросы по тегам