MySQL 8 для 1С-Битрикс: что требует вендор и что ломается при переходе

Про версию PHP вспоминают регулярно, про версию базы данных — почти никогда. При этом требования к ней у 1С-Битрикс такие же жёсткие, а последствия отставания заметны не сразу: сайт работает, пока в одном из запросов не всплывёт режим совместимости или кодировка.

Что требует вендор

В требованиях к серверному программному обеспечению сказано коротко: версия MySQL — 8.0 и выше. Для отечественных Linux-систем (РЕД ОС, ALT, Astra) вендор рекомендует использовать MariaDB вместо MySQL.

Отдельное требование — кодировка. Базе нужна utf8mb4, а не utf8mb3: вторая не покрывает весь Unicode, и на ней теряются эмодзи и часть символов. Сортировка зависит от того, что у вас стоит:

Разница в сортировке — не придирка: utf8mb4_0900_ai_ci в MariaDB просто не существует, и перенос базы между двумя СУБД без правки дампа заканчивается ошибкой на импорте.

Ещё одно, о чём забывают при переносе старых сайтов: с версии продукта 24.0.0 поставки идут только в UTF-8, поддержка windows-1251 прекращена полностью. Сайт в старой кодировке сначала переводится на UTF-8, и только потом речь заходит об обновлениях.

Как проверить, что у вас сейчас

Версию и кодировку показывает проверка системы в административной части: раздел «Настройки — Проверка системы», вкладка с параметрами базы. Там же видно, совпадает ли кодировка таблиц с требуемой.

Если есть доступ к консоли, то же самое видно запросами:

SELECT VERSION();
SELECT @@character_set_database, @@collation_database;
SELECT @@sql_mode;

Третья строка пригодится дальше: именно режим совместимости чаще всего и ломает сайт после перехода.

Что ломается при переходе с 5.7

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

Запросы с группировкой. В режиме ONLY_FULL_GROUP_BY нельзя выбирать поля, которых нет ни в GROUP BY, ни под агрегатной функцией. Старый код этим пользовался свободно, и после перехода такие запросы падают с ошибкой. Лечится либо правкой запроса, либо временным исключением режима из sql_mode — первое правильнее, второе быстрее.

Новые зарезервированные слова. В MySQL 8.0 добавились оконные функции, а вместе с ними ключевые слова: RANK, ROWS, GROUPS, LEAD, LAG и другие. Если в своём коде или в стороннем модуле есть колонка с таким именем без обратных кавычек, запрос перестанет разбираться.

Способ хранения пароля. По умолчанию в 8.0 используется caching_sha2_password. Старый клиент, собранный под mysql_native_password, подключиться не сможет — ошибка выглядит как проблема с правами, хотя дело в методе аутентификации. Решение: либо пересоздать пользователя с нужным плагином, либо обновить клиентскую библиотеку.

Кодировка таблиц. Если база досталась в utf8mb3, конвертация в utf8mb4 увеличивает размер символа с трёх байт до четырёх. На таблицах со старыми индексами длина ключа выходит за допустимый предел, и часть индексов приходится пересобирать. Конвертировать лучше на копии и с замером времени: на базе в несколько гигабайт операция занимает часы.

Порядок перехода

1. Снять полную копию базы и проверить, что она разворачивается. Копия, которую ни разу не восстанавливали, — это не копия.
2. Поднять стенд с целевой версией и развернуть на нём сайт целиком, вместе с модулями Маркетплейса.
3. Пройти по страницам и журналу. Ошибки базы в Битриксе видны в журнале исключений, если он включён; без него вы увидите только общую заглушку.
4. Проверить обмен с 1С и задания планировщика. Они ходят в базу своими запросами, часто написанными давно.
5. Сверить кодировку и сортировку после переноса — и у базы, и у таблиц.
6. Назначить окно для боевого перехода. Для магазина это ночь буднего дня, а не пятница перед акцией.

Когда переход откладывать нельзя

MySQL 5.7 вышел из поддержки производителя в октябре 2023 года, исправления безопасности для него больше не выпускают. С версиями PHP происходит то же самое, об этом у нас отдельный разбор: 31 декабря 2026 из поддержки выходит PHP 8.2. Разница только в том, что база обычно не торчит наружу, и это создаёт ложное ощущение безопасности: добраться до неё можно через сайт, а на взломанном сайте база — первое, что копируют.

Если планируете обновлять окружение целиком, разумно делать это одним заходом: версия PHP, версия базы, кодировка. Так проверять придётся один раз, а не три.

Что делать, если обновлять нельзя

Бывает, что сайт держит хостинг со старой базой, а переезд не планируется. Тогда остаётся защищать периметр: закрыть прямой доступ к базе извне, убрать дампы из публичных папок, проверить, что резервные копии не лежат внутри сайта и не скачиваются по прямой ссылке. На общем хостинге это особенно важно: там статику часто отдаёт nginx мимо правил Apache, и запрет в .htaccess на архивы не срабатывает. Как это выглядит на практике, мы разбирали в кейсе про взломанный сайт.