Я готов перейти от MyISAM к InnoDB, но хотел знать, есть ли полный список вещей, которые нужно искать? Например, я не видел в списке упоминаний о том, что при работе DISABLE KEYSс таблицей InnoDB выдается предупреждение, за исключением страницы руководства для ALTER TABLE. Это то, о чем мне нужно знать, прежде чем переходить. Я думал, что я буду в порядке с моими вопросами, но, видимо, нет.

Вот некоторые ошибки

Использование памяти

MyISAM

• только кеши индексных страниц.
• общий кешированный ключ (размер ключа key_buffer_size).
• Вы также можете настроить выделенный кеширование ключей, одну или несколько таблиц на таблицу кеша .

InnoDB

• кэширует страницы данных и страницы индекса.
• один пул буферов и один размер до MySQL 5.5
• 1 или более буферных пулов, начиная с MySQL 5.5

Вот несколько запросов, которые я написал и опубликовал ранее о том, как выбрать правильный размер для MyISAM Key Cache и InnoDB Buffer Pool .

FULLTEXT индексы

MyISAM

• Поддерживает FULLTEXT индексы

InnoDB

• Начиная с MySQL 5.6, да, но все еще в бета-версии (UPDATE: MySQL 5.6 существует и имеет индексы FULLTEXT. Если вы используете индексирование FULLTEXT в MySQL 5.6, убедитесь, что вы используете специфичные для InnoDB параметры FULLTEXT )
• До MySQL 5.6 это означает, что вы не можете конвертировать MyISAM в InnoDB.

MySQL 5.5 и обратно

Чтобы определить, какие таблицы MyISAM имеют индекс FULLTEXT, выполните этот запрос:

select tbl.table_schema,tbl.table_name from
(
    select table_schema,table_name
    from information_schema.tables
    where engine='MyISAM'
    and table_schema NOT IN ('information_schema','mysql')
) tbl
INNER JOIN
(
    select table_schema,table_name
    from information_schema.statistics
    where index_type='FULLTEXT'
) ndx
USING (table_schema,table_name);

Все, что выходит из этого запроса, не может быть преобразовано в InnoDB, пока вы не обновите MySQL до версии 5.6.

ОПТИМИЗИРУЙТЕ СТОЛ

MyISAM

• Таблица MyISAM сокращена
• ANALYZE TABLE запускает статистику индекса по всем индексам

InnoDB

• ANALYZE TABLE совершенно бесполезен, потому что статистика индекса всегда запоминается
• С innodb_file_per_table инвалидов, ibdata1 будет расти больше
• С innodb_file_per_table включен, файл табличного (.ibd) усаживается

Я думаю, что самая большая проблема была бы в том, чтобы innodb был транзакционным. Вы захотите узнать, используют ли библиотеки MySQL вашими приложениями auto_commit по умолчанию или нет.

Например, Python не выполняет автоматическую фиксацию. Это означает, что если приложение вставляло строку непосредственно перед закрытием соединения, то вставка теперь будет откатываться после того, как вы измените innodb. Например, скрипт python должен обязательно вызывать connection.commit ();

Еще одна разница может заключаться в многострочных вставках или обновлениях. Рассмотрим одну многорядную вставку

insert into tbl values (...row1...),  (...row2...),  (...rowN....);

Подумайте, что произойдет, если возникнет какая-то ошибка, например, столкновение уникального ключа в строке 3. С MyISAM первые две строки были бы записаны, при innodb все записываемые строки будут откатываться, не оставляя ничего записанного даже при такой ошибке.

С innodb вы попадете в мир тупиков. Это не плохо по своей природе, если они не происходят с такой частотой, чтобы предотвратить выполнение какой-либо работы. Однако ваши приложения должны быть закодированы таким образом, чтобы они предвидели взаимные блокировки и обрабатывали их соответствующим образом (что, скорее всего, означает просто повторную попытку).

Учитывайте ограничения памяти / памяти. Innodb намного более ресурсоемкий, чем MyISAM. Если у вас достаточно оперативной памяти для того, чтобы ваши буферные пулы были достаточно большими, чтобы вместить все ваши таблицы, тогда вы великолепны

Ищите таблицы с большими первичными ключами. Кластерная индексация Innodb означает, что каждый вторичный индекс содержит другую копию PK соответствующей строки. Если у вас есть 2 вторичных индекса, это означает, что каждая строка PK сохраняется 3 раза (PK + каждый индекс). Если pk охватывает несколько столбцов и большие типы данных (например, char (N)), вы можете увидеть, как требования к индексу могут быстро взорваться в innodb.