InnoDB и MyISAM в MySQL: разница и что выбрать

Чем принципиально отличаются InnoDB и MyISAM

На сервере MySQL и MariaDB каждая таблица хранится и обрабатывается через движок хранения — модуль, который определяет формат файлов на диске, поддержку транзакций и поведение при блокировках. С версии MySQL 5.5 движком по умолчанию стал InnoDB, но на старых проектах и в отдельных схемах ещё встречается MyISAM. Разница между InnoDB и MyISAM не косметическая: от выбора движка зависит, переживёт ли таблица аварийный перезапуск сервера без потери и порчи данных.

Транзакции и блокировки на уровне строк

InnoDB пишет изменения в журнал транзакций и умеет откатывать (ROLLBACK) незавершённую операцию. Это критично для интернет-магазина: если платёж прервался на середине записи заказа, InnoDB откатит все связанные вставки, а не оставит заказ в половинчатом состоянии. MyISAM транзакций не знает вовсе — любая операция сразу фиксируется на диске.

Второе отличие — гранулярность блокировок. MyISAM блокирует всю таблицу на время записи, поэтому параллельные SELECT ждут в очереди. InnoDB блокирует только те строки, которые реально изменяет запрос, и параллельные читатели и писатели почти не мешают друг другу благодаря MVCC.

Что происходит при аварийном завершении сервера

При отключении питания или kill -9 процесса mysqld таблицы InnoDB восстанавливаются автоматически при следующем старте: сервер читает redo-журнал и доигрывает незафиксированные транзакции. Администратору обычно не нужно ничего делать руками.

С MyISAM всё иначе: файл таблицы может остаться в повреждённом состоянии, и сервер откажется с ним работать, пока не выполнить REPAIR TABLE или myisamchk. На больших таблицах восстановление занимает часы, а часть строк в худшем случае теряется безвозвратно. Подробнее о резервных копиях, которые страхуют от такой ситуации, смотрите в статье про резервное копирование mysqldump.

Когда MyISAM ещё оправдан

Несмотря на возраст движка, у него остаются узкие сценарии применения:

• Таблицы только для чтения — архивы логов, справочники, которые не изменяются после загрузки.
• Полнотекстовый поиск на старых версиях MySQL без встроенной поддержки FULLTEXT в InnoDB.
• Импорт разовых выгрузок, где важна скорость массовой вставки, а целостность проверяется отдельно.
• Legacy-код старых CMS, который жёстко рассчитан на поведение MyISAM и его не планируют переписывать.

Как узнать, какой движок использует таблица

Быстрее всего посмотреть движок через SHOW TABLE STATUS или через information_schema:

SHOW TABLE STATUS FROM shop LIKE 'orders'\G

SELECT table_name, engine FROM information_schema.tables WHERE table_schema='shop';

Если в выводе поле Engine показывает MyISAM для таблицы, где ожидаются транзакции, это повод для миграции. Заодно проверьте типы индексов — статья про оптимизацию индексов MySQL объясняет, как индексы ведут себя по-разному на InnoDB и MyISAM.

Как перевести таблицу с MyISAM на InnoDB

Перед конвертацией снимите резервную копию, затем выполните смену движка одной командой:

ALTER TABLE shop.orders ENGINE=InnoDB;

На таблицах в несколько гигабайт операция блокирует запись на время перестроения и может занять десятки минут. Для продакшена без простоя используйте pt-online-schema-change из набора Percona Toolkit — он копирует данные в фоне и подменяет таблицу атомарно. После конвертации проверьте параметры буферного пула InnoDB в конфиге — им посвящена отдельная статья про настройку my.cnf.

Итог: что выбрать для своих таблиц

Для подавляющего большинства новых проектов правильный выбор — InnoDB, и MySQL 8.0 использует его по умолчанию без дополнительных настроек. Перед тем как оставить MyISAM в старой схеме, пройдитесь по чек-листу:

• Нужны ли таблице транзакции или внешние ключи — тогда только InnoDB.
• Важна ли устойчивость к аварийному перезапуску сервера без ручного восстановления.
• Есть ли параллельная запись из нескольких соединений одновременно.
• Действительно ли таблица статична и меняется не чаще раза в сутки.
• Проверена ли резервная копия перед любой миграцией движка.