Объединение таблиц InnoDB с таблицами MyISAM

У нас есть набор таблиц, которые содержат данные мета-уровня, такие как организации, пользователи организаций, отделы организации и т. Д. Все эти таблицы будут интенсивно читать с очень небольшим количеством операций записи. Кроме того, размеры таблицы будут довольно небольшими (максимальное количество записей будет около 30-40К).

Другой набор таблиц хранит данные OLTP, такие как транзакции счетов, действия пользователя и т. Д., Которые будут тяжелыми как для чтения, так и для записи. Эти таблицы будут довольно огромными (около 30 миллионов записей на таблицу).

Для первого набора таблиц мы планируем использовать MyISAM, а для второго - движок InnoDb. Многие из наших функций также потребуют JOINS для таблиц из этих двух наборов.

Есть ли проблемы с производительностью при объединении таблиц MyISAM с таблицами InnoDB? Кроме того, есть ли другие возможные проблемы (резервное копирование базы данных, настройка и т. Д.), С которыми мы могли бы столкнуться при таком дизайне?

Любая обратная связь будет принята с благодарностью.


mysql innodb myisam
person Pigol    schedule 29.03.2011    source источник

Ответы (2)


arrow_upward
50
arrow_downward

Мне сразу бросается в глаза MyISAM.

АСПЕКТ №1: Сам JOIN

Всякий раз, когда происходит объединение с участием MyISAM и InnoDB, таблицы InnoDB в конечном итоге будут иметь поведение блокировки на уровне таблицы вместо блокировки на уровне строки из-за участия MyISAM в запросе и MVCC нельзя применить к данным MyISAM. MVCC в некоторых случаях даже нельзя применить к InnoDB.

АСПЕКТ № 2: Участие MyISAM

С другой стороны, если какие-либо таблицы MyISAM обновляются с помощью INSERT, UPDATE или DELETE, таблицы MyISAM, участвующие в запросе JOIN, будут заблокированы от других подключений к БД, и запрос JOIN должен ждать, пока таблицы MyISAM не будут прочитаны. К сожалению, если в запросе JOIN используется сочетание InnoDB и MyISAM, таблицы InnoDB должны будут испытывать периодическую блокировку, как и его партнеры MyISAM в запросе JOIN, из-за задержки записи.

Имейте в виду, что MVCC по-прежнему будет разрешать транзакции READ-UNCOMMITTED и REPEATABLE-READ работать нормально, а определенные представления данных будут доступны для других сделки. Я не могу сказать то же самое о READ-COMMITTED и SERIALIZABLE.

АСПЕКТ № 3: Оптимизатор запросов.

MySQL полагается на количество элементов индекса для определения оптимизированного плана EXPLAIN. Мощность индекса в таблицах MyISAM остается стабильной до тех пор, пока с таблицей не произойдет множество операций INSERT, UPDATE и DELETE, с помощью которых вы могли бы периодически запускать OPTIMIZE TABLE для таблиц MyISAM. Мощность индекса InnoDB НИКОГДА НЕ СТАБИЛЬНАЯ !!! Если вы запустите SHOW INDEXES FROM *innodbtable*;, вы будете видеть изменение количества элементов индекса каждый раз, когда запускаете эту команду. Это потому, что InnoDB будет углубляться в индекс, чтобы оценить мощность. Даже если вы запустите OPTIMIZE TABLE для таблицы InnoDB, это приведет только к дефрагментации таблицы. OPTIMIZE TABLE будет запускать ANALYZE TABLE внутренне для генерации статистики индекса по таблице. Это работает для MyISAM. InnoDB игнорирует это.

Мой вам совет - изо всех сил конвертировать все в InnoDB и соответствующим образом оптимизировать ваши настройки.

ОБНОВЛЕНИЕ 2012-12-18 15:56 EDT

Вы не поверите, но существует все еще открытый билет на присоединение к InnoDB / MyISAM во время ВЫБРАТЬ ДЛЯ ОБНОВЛЕНИЯ. Если вы его читаете, резолюция резюмируется следующим образом: НЕ ДЕЛАЙТЕ ЭТО !! !.

person RolandoMySQLDBA    schedule 29.03.2011
comment
Спасибо за подробное объяснение, Роландо. Если таблицы InnoDb также будут страдать от блокировок на уровне таблицы при объединении с таблицами MyISAM, это значительно повлияет на наши транзакции OLTP. Мы продолжим только с InnoDB. Еще раз спасибо. - person Pigol; 30.03.2011

arrow_upward
0
arrow_downward

Я не думаю, что управление транзакциями будет работать должным образом или вообще, поскольку таблицы MyISAM не справляются с этим.

person xecaps12    schedule 29.03.2011