Соединение таблиц InnoDB с таблицами MyISAM

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

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

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

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

Приветствуется любая обратная связь.

Ответ 1

То, что сразу же появляется у меня, - MyISAM.

АСПЕКТ # 1: САЙТ

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

ASPECT # 2: участие MyISAM

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

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

ASPECT # 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 во время SELECT FOR UPDATE. Если вы его прочитали, он суммирует разрешение следующим образом: НЕ ДЕЛАЙТЕ ЭТО!!!.

Ответ 2

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