Оптимальный движок для небольших таблиц поиска в MySQL.

Question

У меня есть следующий вопрос:Я разрабатываю веб-приложение с несколькими десятками небольших таблиц поиска:Эти таблицы обычно содержат три столбца (ID, Имя, Описание) и пару строк (чаще всего менее 50, максимальное — около 450).

Ожидается, что эти таблицы поиска будут меняться лишь изредка (они взяты из стандарта, который меняется раз в несколько лет) и будут использоваться только для:

• варианты заполнения в html select
• присоединяться к другим записям в отчетах

Будет только SELECT утверждения по этим таблицам в 99% случаев, но их будет довольно много.

Мне интересно, какой механизм базы данных будет наиболее эффективным в использовании?

Вот мои соображения:

ОБЪЕМ ПАМЯТИ

• про:очень быстро
• против:в случае сбоя сервера все данные теряются и их необходимо воссоздать
• против:не поддерживает внешние ключи

сжатый MyISAM

• про:быстрый
• против:не поддерживает внешние ключи

ИнноДБ

• про:поддержка внешнего ключа

Я хотел бы спросить, будет ли значительное преимущество в использовании чего-то отличного от ИнноДБ - с точки зрения производительности

Спасибо, Збинек

Answer 1

Я ответил на аналогичный вопрос в августе 2011 года: Какая СУБД хороша для сверхбыстрого чтения и простой структуры данных?

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

Вот некоторые из моих прошлых постов по этому спору.

• Sep 20, 2011 : Лучшее из MyISAM и InnoDB
• May 03, 2012 : Что быстрее, InnoDB или MyISAM?
• Jul 05, 2012 : InnoDB против MyISAM со множеством индексов
• Sep 26, 2012 : Выбор MyISAM вместо InnoDB для этих требований проекта;и долгосрочные варианты

Вы можете спросить прямо сейчас:Почему я предпочитаю MyISAM InnoDB?

Взгляните на эту диаграмму (создана Вадимом Ткаченко, техническим директором Percona)

MyISAM будет кэшировать индексы, и ваша таблица будет иметь 2 индекса (ПЕРВИЧНЫЙ КЛЮЧ по идентификатору и индекс имени).С другой стороны, InnoDB имеет слишком много движущихся частей, особенно если буферный пул InnoDB должен периодически загружать и удалять 16 КБ страниц.

Справедливости ради стоит провести эксперимент.

• Перейти к моему сообщению Каковы основные различия между InnoDB и MyISAM?.Прочтите внимательно.
• Настройте сервер, используя MyISAM, и все ваши таблицы, используя ROW_FORMAT=Fixed (см. мой пост Каково влияние на производительность использования CHAR и VARCHAR в поле фиксированного размера?) и используйте большой key_buffer_size.
• Настройте другой сервер, используя InnoDB и большой innodb_buffer_pool_size.
• Добавьте свои данные на оба сервера и запрашивайте их как сумасшедшие.

Это даст вам наилучшую оценку выбора Storage Engine для вашего набора данных.

ПОПРОБУЙТЕ!!!

Answer 2

• «Сжатый MyISAM» — что это?Может быть, «Архив»?
• Сжатие не требуется;таблицы слишком малы и быстро будут полностью кэшированы.
• FOREIGN KEYS -- Почему?Вы отладили свой код, не так ли?Не будет никаких висящих вещей, которые можно было бы проверить.
• MEMORY не является необоснованным, если вы пишете код «перезагрузки», который выполняется всякий раз, когда вы запускаете сервер, и любые обновления таблицы записываются как в MEMORY таблица и постоянная резервная копия.
• MyISAM ROW_FORMAT=FIXED -- это бабушкина сказка;использовать DYNAMIC и VARCHARs.
• «Кластеризованный» InnoDB PRIMARY KEY делает поиск немного быстрее, чем MyISAM для ваших целей.
• Ты знать что таблицы поиска вызывают заметное замедление?Я серьезно сомневаюсь, что они есть.
• Делать нет используйте таблицы поиска для «непрерывных» значений, таких как FLOATs и DATEs.

Я голосую за InnoDB без FK.