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


16

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

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

Ответы:


6

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

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

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

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

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

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


Если вы заинтересованы в тестах, попробуйте sysbench или iibench.
Джодер Хо,

Являются ли какие-либо альтернативные механизмы хранения достаточно стабильными, чтобы они подходили для производственной площадки?
Тони Мейер

Дон Макаскилл планирует запустить XtraDB в производство. YMMV.
Джодер Хо

Производительность - не единственное требование - рассмотрим также и эксплуатационные проблемы (на самом деле, как я
понимаю,

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

5

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

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


1
Для любой рабочей нагрузки, которая смешивает чтение и запись, InnoDB является единственным вариантом (который в настоящее время поставляется).
Дейв Чейни

4

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

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


4

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

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

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

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

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

2
Вы действительно думаете, что механизм баз данных - это решение разработчика, а не администраторов? Как разработчик, я хочу сказать: «У меня есть эти данные, с которыми я буду это делать», и оставить оптимизацию (и резервное копирование, и ...) базы данных администратору.
Тони Мейер

1
Да, разработчик должен иметь возможность разрабатывать и тестировать свое приложение на конкретном движке; они ведут себя совершенно по-разному как функционально, так и по производительности.
MarkR

2

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

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

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

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

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


Только выберите count ( ) из таблицы быстрее в MyISAM. Выберите count ( ) из таблицы, где column = value имеет одинаковую производительность как для MyISAM, так и для InnoDB. mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables
sumar
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.