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

Question

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

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

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

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

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

Answer 1

Что сразу бросается в глаза, это MyISAM .

АСПЕКТ №1: само СОЕДИНЕНИЕ

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

Answer 2

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