Назад | Перейти на главную страницу

Как выбрать ядро ​​базы данных MySQL

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

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

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

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

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

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

  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, а не Stack Overflow, поэтому правильный ответ:

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

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

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

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

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

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