Выбор механизма хранения MySQL: InnoDB и наследие MyISAM в проектах на Битрикс

Что такое «тип таблицы» в MySQL

Сервер умеет хранить строки разными механизмами хранения (storage engines): от набора файлов на диске до чисто оперативных структур. Для одной схемы смешение движков нормально: у части таблиц — один формат, у других — другой. Выбор влияет на целостность данных, поведение под нагрузкой и стоимость администрирования — не только на «цифры в бенчмарке».

Кратко о типичных движках

• MyISAM — классика старых инсталляций: таблица как три файла (.MYD, .MYI, .frm в эпоху до 8.0), грубая блокировка на уровне таблицы, без полноценных транзакций ACID. До MySQL 5.5.5 часто был движком по умолчанию для новых таблиц.
• InnoDB — с MySQL 5.5.5 по умолчанию для новых таблиц; строковые блокировки, MVCC, журнал и восстановление после аварий, внешние ключи, кластерный первичный ключ.
• MEMORY — данные в RAM; после рестарта содержимое пропадает, удобно для временных вычислений, не для постоянного каталога заказов.
• ARCHIVE — сжатое хранение «ленты» событий, холодные логи.
• CSV — таблица как набор CSV-файлов; обмен и отладка, не основной контур Битрикс.

В экосистеме MariaDB к MyISAM добавляли Aria как более предсказуемую замену; исторические эксперименты вроде отдельных «ускорителей» под конкретные нагрузки сегодня вторичны по сравнению с зрелым InnoDB.

MyISAM и InnoDB: что сравнивать на практике

У MyISAM чтение без конкурирующей записи может быть очень быстрым, а простые массовые вставки иногда дешевле по метаданным — но цена — блокировка всей таблицы на запись, риск повреждения при обрыве питания и отсутствие отката по транзакции. InnoDB держит согласованность через буфер и redo-лог: тяжелее восстановление «в лоб», зато после сбоя не нужен ритуал с REPAIR TABLE на пользовательских данных.

С точки зрения типовых задач веб-проекта — корзина, обмен с 1С, одновременное редактирование в админке — выигрывает модель со строковыми блокировками и явными транзакциями.

Почему для Битрикс разумно смотреть на InnoDB

Ядро и модули опираются на связность таблиц, повторные чтения в одном запросе и одновременные сессии. Оставлять боевые сущности на MyISAM в 2020-х — сознательный архитектурный долг: сложнее бороться с гонками, бэкапы и репликация предъявляют те же требования, что и к любому OLTP-приложению. Полнотекстовый поиск в MyISAM когда‑то оправдывался нативными индексами; для качественного поиска по каталогу чаще выносят Sphinx, Elasticsearch или штатные возможности с релевантностью, а не упираются в ограничения одного движка таблицы.

Миграция существующей таблицы

Классическая команда:

ALTER TABLE b_example ENGINE=InnoDB;

На больших таблицах операция может занять часы и держать блокировки — планируйте окно обслуживания и контроль по диску. Перед массовым переводом стоит проверить дубли уникальных полей: старый приём с ALTER IGNORE и принудительным уникальным индексом ведёт себя по-разному в разных версиях; надёжнее сначала найти и устранить дубликаты запросами к диагностике, а уже потом включать ограничения.

Итог

Для новых проектов на стеке MySQL/MariaDB и 1С‑Битрикс ориентир простой: InnoDB как базовый движок пользовательских и типовых модулей, осознанные исключения — только там, где архитектура и тесты это подтверждают.