Битрикс и MySQL: подключение, версии и переход на MySQL 8 без 500-х ошибок

Битрикс и MySQL: что реально требует вендор в 2026 году

После обновления ядра на проекте с 5.7 в админке всплывает красная плашка «Режим работы MySQL» — и это не косметика, а сигнал, что вендор уже не считает вашу СУБД поддерживаемой. У нас в практике такие проверки чаще всего прилетают на клиентах, которые годами не трогали сервер: сайт работает, выгрузки идут, а потом одно обновление — и половина привычного стека объявлена устаревшей. Чтобы не ловить это в момент релиза, полезно держать в голове актуальные требования вендора.

Официально минимальная версия PHP — 8.2.0, и требование вступает в силу с 1 февраля 2026 года. По базам данных формулировка жёстче, чем кажется: MySQL 8.0 — это минимум, а не рекомендация, и вендор отдельно указывает «8.0 и выше» как рекомендуемый вариант. По веб-серверу — Apache 2.0+ (рекомендуется 2.4.x), либо nginx последней стабильной ветки, желательно 1.16.x и выше, но с важной оговоркой: для nginx нужна самостоятельная настройка, из коробки он с Битриксом не работает.

И ещё: поддержку MySQL в самом PHP нужно включать отдельно — для старого ядра (dbconn.php) и для нового (.settings.php).

Для коробочного Битрикс24 и «1С-Битрикс: Управление сайтом» формулировки в источниках расходятся — по опыту подрядчиков требования к редакциям совпадают не дословно, поэтому сверяйтесь с конкретной документацией под свой продукт.

Почему вендор вообще поднял планку — вопрос не вкуса, а совместимости. MySQL 8.0.3 удалил query cache и связанные с ним переменные, поэтому старые конфиги, где в my.cnf прописан query_cache_size или query_cache_type, ломают старт сервера: MySQL просто не поднимется с незнакомым параметром. Это первое, с чем сталкиваются при переезде с 5.7.

Второй пласт — то, ради чего ядро постепенно переезжает на новые возможности. utf8mb4 становится кодировкой по умолчанию, что снимает старые костыли с эмодзи и 4-байтовыми символами, но требует, чтобы вы сверили коллации на существующих таблицах. Плюс оконные функции — ядро Битрикса всё чаще использует их в выборках, а на 5.7 их попросту нет. Отсюда и общий смысл требования: 8.0 — это не «модно», а нижняя граница, на которой ядро гарантированно работает без патчей.

Что делать прямо сейчас: проверьте версию MySQL и параметры innodb_strict_mode, sql_mode и размер innodb_buffer_pool — об этом ниже разберём отдельно, потому что именно здесь всплывают самые частые грабли при переходе.

Как настроить подключение Битрикс к MySQL: dbconn.php и .settings.php

Типичный сценарий: переносите сайт на новый сервер, вбиваете свежие креды — а через сутки выясняется, что часть ядра ходит по старым реквизитам. Исторически в Битриксе оказалось два файла подключения к БД, и оба живые. Старый — /bitrix/php_interface/dbconn.php с переменными $DBHost, $DBLogin, $DBPassword, $DBName. Новый — /bitrix/.settings.php с секцией core (начиная с 14-й версии ядра). Официальная документация вендора прямо говорит: специальные переменные можно определить только в файле, хранящем параметры соединения — то есть в dbconn.php. А конфигурация D7 читает .settings.php.

Что это значит на практике. Если поправить только один файл — получите классику «сайт открывается, а cron падает» или «админка работает, а CLI-скрипты не коннектятся». У нас в практике это самая частая причина «странных» ошибок после переезда. Поэтому смотрим оба файла и правим синхронно — сначала dbconn.php для старого ядра, потом .settings.php для D7. Ниже — рабочий вид обоих.

<?php
// /bitrix/.settings.php — фрагмент, секция core (D7)
return [
    'core' => [
        'host' => 'localhost',
        'login' => 'bitrix_user',
        'password' => 'strong_password',
        'database' => 'bitrix_db',
    ],
    // ... остальные секции: cache, session, exception_handling
];

Что делать с константами DELAY_DB_CONNECT и CACHED_menu

Обе константы объявляются только в dbconn.php — в .settings.php их нет и быть не может. Это ещё одна причина, почему нельзя выкинуть старый файл: часть настроек живёт исключительно там. Если вы переносите сайт и копируете только .settings.php, константы молча теряются, и поведение ядра меняется незаметно.

По умолчанию DELAY_DB_CONNECT выключена — соединение с MySQL устанавливается сразу при инициализации ядра. Включать её стоит осознанно: она полезна на страницах, которые вообще не трогают базу (статика, отдача файлов, healthcheck-эндпоинты). CACHED_menu задаёт TTL управляемого кеша меню в секундах; если поставить false — кеширование меню отключается полностью, что оправдано только на этапе активной разработки.

DELAY_DB_CONNECT откладывает установку соединения до первого запроса через API-функции ядра. То есть пока код не дёрнул CDatabase::Connect() или любую обёртку над ним — коннекта нет. На страницах, где БД не нужна, это экономит один round-trip к MySQL и снимает нагрузку с сервера БД при всплесках трафика на статику. Но осторожно: если вы полагаетесь на то, что соединение уже установлено (например, свой код в init.php дёргает $DB напрямую до первого API-вызова), отложенный коннект даст «тихий» сбой в неожиданном месте.

CACHED_menu работает через управляемый кеш и влияет на компоненты меню. Разумное значение — от 3600 секунд для стабильных меню до 300–600 для часто меняющихся. Ставить false на проде не стоит: каждое построение меню — это запросы к b_iblock_section и связанным таблицам, и на каталоге с глубокой вложенностью разделов это заметная нагрузка. Обе константы объявляются в начале dbconn.php, до переменных подключения — так их точно подхватит и старое, и новое ядро.

Как проверить текущую версию MySQL и что показывает «Режим работы MySQL»

В админке Bitrix есть страница «Режим работы MySQL» — и это первое, куда мы смотрим при диагностике любой непонятной ошибки базы. Она проверяет версию сервера, состояние innodb_strict_mode, innodb_large_prefix, sql_mode и целый список параметров, которые вендор считает обязательными для стабильной работы ядра. Страница живёт в разделе «Настройки → Инструменты → Проверка системы» и обновляется при каждом заходе, то есть показывает срез прямо сейчас, а не на момент установки.

Красный статус на этой странице — не косметика и не «предупреждение на будущее». Это реальная причина будущих 500-х, залипших агентов и битых транзакций при импорте. Ошибка innodb_strict_mode=ON вылезает в самый неподходящий момент: когда пользователь жмёт «Оформить заказ», а не когда вы правите конфиг.

Поэтому проверку версии и режима мы делаем до того, как что-то сломалось, а не после.

Кстати, версию MySQL полезно знать не только для диагностики: минимальное требование вендора — MySQL 8.0, и на 5.7 новые релизы ядра уже не тестируются. Если у вас 5.7 — это первый сигнал планировать переезд.

Есть четыре способа узнать текущую версию — от самого быстрого к самому подробному:

1. Админка → «Режим работы MySQL» — покажет версию и все критичные параметры одной страницей.
2. mysql -V в шелле — версия клиента; быстрее всего, если есть SSH.
3. SELECT VERSION() через mysql-клиент — версия сервера, а не клиента, что важнее.
4. Через CDatabase::Connect в отладочном скрипте — если нет доступа к консоли, но есть доступ к сайту.

Для третьего способа достаточно одного запроса, который заодно покажет критичные переменные:

SELECT VERSION() AS mysql_version, @@ innodb_strict_mode AS strict_mode, @@ sql_mode AS sql_mode, @@ max_allowed_packet AS max_packet;

Как читать вывод — три параметра из четырёх важны сразу. innodb_strict_mode должен быть OFF: при ON ядро отдаёт ошибку 1227 Access Denied на операциях, которые в нестрогом режиме проходят молча. sql_mode должен быть пустой строкой — значение NO_ENGINE_SUBSTITUTION вызывает критичную ошибку, которая может привести к блокировке запросов к базе. max_allowed_packet в VMBitrix выставляется в 1024M: если у вас меньше, крупные импорты из 1С будут рваться на середине пакета.

Если хоть один параметр не тот — идём править my.cnf (в VMBitrix это /etc/mysql/conf.d/z_bx_custom.cnf) и перезапускаем MySQL. Правки в рантайме через SET GLOBAL не переживут рестарта, поэтому конфиг — единственный надёжный путь. Об этом подробно в следующей секции.

Ошибка innodb_strict_mode=ON: как отключить и почему это не «костыль»

Самый частый запрос на эту тему звучит так: «перенёс сайт на новый сервер — в админке висит "innodb_strict_mode=ON, требуется OFF", что делать?» И почти сразу второй вопрос: «это точно не костыль, я ничего не сломаю?» Отвечаем сразу: не костыль. Это требование ядра, и вендор сам выставляет параметр в своих эталонных сборках.

Смотрите: в BitrixVM файл /etc/mysql/conf.d/z_bx_custom.cnf уже содержит innodb_strict_mode=OFF — вместе с max_allowed_packet = 1024M и sync_binlog = 0. То есть вендор не просто «разрешает» отключить строгий режим, он сам его отключает в рекомендованной конфигурации. Если вы разворачиваете Битрикс на кастомном сервере (не VMBitrix), этот файл никто не создаст, и параметр останется дефолтным для MySQL 8.0 — то есть ON. Отсюда и ошибка.

Проверка «Режим работы MySQL» в админке появляется после обновления модуля main до версии 19.0.400 — она и подсвечивает несоответствие. Дальше правится в одну правку конфига:

# откройте конфиг (путь зависит от дистрибутива)
sudo nano /etc/mysql/conf.d/z_bx_custom.cnf
# либо, если файла нет:
sudo nano /etc/mysql/my.cnf

# добавьте в секцию [mysqld]:
[mysqld]
innodb_strict_mode = OFF

# перезапустите MySQL
sudo service mysqld restart
# или, в зависимости от системы:
# sudo systemctl restart mysql

После перезапуска обновите страницу «Режим работы MySQL» — статус должен стать зелёным. Если конфиг лежит в /etc/mysql/my.cnf, убедитесь, что секция [mysqld] не дублируется ниже — MySQL возьмёт последнее значение, и если там снова ON, ничего не изменится.

Почему OFF безопасен для данных. Строгий режим InnoDB заставляет сервер падать с ошибкой на нестандартных типах и размерах полей — например, на VARCHAR длиннее допустимого для текущего row format или на устаревших конструкциях, которые Битрикс исторически использует в миграциях и старых модулях. Отключение режима не трогает сами данные — оно лишь снимает блокировку на легаси-схемы, которые ядро всё равно создаёт и читает. По сути вы разрешаете MySQL быть терпимее там, где платформа этого требует.

Заодно проверьте соседний параметр — innodb_large_prefix. Если он OFF, его тоже нужно перевести в ON: без этого индексы на длинных VARCHAR не создадутся, и часть миграций Битрикса отвалится уже на другом шаге. Оба параметра живут в одной секции [mysqld] — правьте их за один заход, чтобы не перезапускать MySQL дважды.

Как перейти с MySQL 5.7 на 8.0 в Битриксе: пошаговый план

Значит, остаётся два пути: дамп-рестор на чистый сервер или логическая репликация со старого мастера на новый. Оба рабочие, но по нашей практике на проектах с активным обменом с 1С надёжнее идёт дамп-рестор на стейдже — там спокойно обкатываешь, ловишь сюрпризы с кодировками и sql_mode , и только потом катишь на прод.

Порядок действий, который у нас устоялся, — ниже. Он не отменяет общих требований вендора к версии MySQL 8.0, о которых мы говорили выше, а показывает, как именно пройти этот переход без простоя и без «сюрпризов» в проде.

1. Зафиксировать текущее состояние. Снять полный дамп базы: mysqldump --single-transaction — для таблиц InnoDB флаг --single-transaction даёт консистентный снимок без блокировки таблиц. Отдельно выписать текущие значения sql_mode и innodb_strict_mode на источнике — они понадобятся, чтобы понять, что именно придётся подкручивать на приёмнике.
2. Поднять чистый MySQL 8.0 на отдельном хосте. Не на том же сервере, где крутится 5.7 — иначе рискуете случайно задеть рабочие данные. Сразу прописать z_bx_custom.cnf с настройками, которые требует Битрикс: innodb_strict_mode=OFF, max_allowed_packet=1024M, sync_binlog=0. Это те же параметры, что мы разбирали в секции про строгий режим InnoDB — здесь они просто переносятся на новый инстанс.
3. Залить дамп. mysql < dump.sql на новом сервере. После заливки — обязательно проверить кодировку (utf8mb4 должна быть и на уровне базы, и на уровне таблиц) и сверить количество строк в ключевых таблицах: b_iblock_element, b_catalog_price. Расхождение хотя бы в одной — стоп, разбираемся до переключения.
4. Переключить Битрикс на новый хост. Правим dbconn.php и .settings.php — реквизиты должны совпадать в обоих файлах, иначе часть ядра уйдёт по старым. Чистим кеш и прогоняем полный обмен с 1С на стейдже: это самый быстрый способ поймать несовместимости, которые не видны на пустой базе.
5. Проверить «Режим работы MySQL» в админке. Все галочки должны быть зелёными, ошибок — ноль. Только после этого переключаем прод. Если хоть одна проверка красная — не катим, разбираемся с конкретным параметром.

Почему в корневом меню статус «выполнился с ошибкой»

После перехода на 8.0 в корневом меню часто висит статус «выполнился с ошибкой» — и это не сломанный сайт, а непройденная проверка вендора. На форумах dev.1c-bitrix.ru этот симптом разбирали неоднократно: сама платформа работает, ошибок в логах PHP нет, а в меню — красный статус.

Причина обычно одна из двух. Первая — query_cache_size: переменной больше нет в MySQL 8.0.3+, её просто удалили из ядра. Если в вашем my.cnf она осталась — сервер либо не стартует, либо игнорирует её, а проверка Битрикса видит несоответствие. Вторая — sql_mode: на 8.0 дефолт отличается от 5.7, и часть режимов ломает запросы старого ядра.

Как лечим: смотрим лог проверки (он открывается по клику на статус), находим конкретную переменную, убираем её из конфига или приводим к ожидаемому значению, перезапускаем MySQL. Статус становится зелёным. Ничего в коде Битрикса трогать не нужно.

Битрикс переход на MySQL 8: что ломается в конфигах и коде

MySQL 8.0 — это не «просто новая версия» с теми же правилами игры. Вендор убрал query cache целиком вместе со всеми связанными переменными (query_cache_size, query_cache_type, query_cache_limit), сменил дефолтный charset на utf8mb4, ужесточил парсинг sql_mode и добавил оконные функции. Для Битрикса это означает одно: конфиги и код, которые спокойно жили на 5.7 годами, на 8.0 начинают падать — иногда сразу, иногда через неделю после переезда.

У нас в практике почти каждый переход даёт 2-3 неожиданных падения. И почти всегда они прилетают не из ядра — ядро вендор правит под новые требования — а из кастомных модулей и старых агентов, которые писались под 5.6 и с тех пор никто не трогал. Типичная картина: сайт поднялся, каталог открывается, а ночью падает cron с обменом, потому что агент дёргает запрос с GROUP BY без агрегата.

Ниже — матрица того, что ломается чаще всего, и как это чинить.

Кастомные модули и прямые SQL-запросы

Основная масса проблем приходит оттуда, куда ядро не дотягивается — из самописных модулей и обработчиков, где разработчики ходили в базу напрямую. На 5.7 запрос вида SELECT ID, NAME, PRICE FROM b_catalog_price GROUP BY ID проходил молча: сервер сам выбирал произвольное значение NAME и PRICE. На 8.0 с включённым ONLY_FULL_GROUP_BY тот же запрос падает с ошибкой.

Отдельная категория — старые агенты, которые никто не переписывал с момента запуска проекта. Они стреляют по крону, падают в лог, а админ видит только «ошибка выполнения агента» без деталей. Мы обычно первым делом прогоняем все агенты через agent.php вручную и смотрим, какие из них ходят в базу прямыми запросами.

Третья зона риска — кастомные компоненты с $DB->Query(). Старый API не экранирует и не валидирует ничего, а на 8.0 ужесточился не только sql_mode, но и парсинг запросов. В таких случаях мы не переписываем на D7 сразу — сначала правим запросы минимально, чтобы сайт поднялся, потом рефакторим по мере сил. Если модулей много, есть смысл завести отдельный лог для медленных и падающих запросов — так хотя бы видно, откуда именно сыпется.

Если в проекте есть модули с прямыми запросами через $DB->Query() и GROUP BY без агрегирующих функций — на 8.0 они упадут с ONLY_FULL_GROUP_BY. Вариантов ровно два: либо правим запросы и добавляем в SELECT все неагрегированные поля из GROUP BY (или оборачиваем их в MIN()/MAX()/ANY_VALUE()), либо временно ставим sql_mode пустым. Вендор рекомендует именно пустой sql_mode — по документации это штатная конфигурация для Битрикса, а не костыль.

Мы обычно идём смешанным путём: sql_mode ставим пустым сразу, чтобы сайт работал, а запросы правим постепенно, по мере обнаружения. Полагаться только на пустой sql_mode не стоит: он маскирует проблемы, которые вылезут при следующем апгрейде или при переезде на другой сервер, где конфиг будет строже.

grep -E 'query_cache|sql_mode' /etc/mysql/**/*.cnf

Почему падает сайт с 500 после правки mysqlcommonconnection.php

Распространённая ошибка: файл ядра открывают в редакторе, чтобы «посмотреть» или «на всякий случай поправить», сохраняют — и сайт немедленно отдаёт 500 Internal Server Error. В логе при этом видно характерную строку:

PHP Fatal error: Namespace declaration statement has to be the very first statement in the script
in /var/www/site/bitrix/modules/main/lib/db/mysqlcommonconnection.php on line 2

Файл при этом выглядит нормально — на второй строке честно стоит namespace Bitrix\Main\DB;, синтаксис не трогали. На ru.stackoverflow разбирали ровно такой случай: сайт работал, потом внезапно начал падать с этим фаталом, при этом в самом коде никто ничего не менял. Причина оказалась не в логике, а в невидимых байтах перед открывающим тегом.

PHP требует, чтобы namespace был самой первой инструкцией скрипта. Если перед <?php оказался хотя бы один байт — пробел, перевод строки, маркер BOM — интерпретатор считает, что первым идёт вывод, и объявление namespace уже «не первое». Дальше — фатал, 500 и белый экран вместо сайта.

Откуда байты берутся: редактор по умолчанию сохранил файл в UTF-8 с BOM, а ядро Битрикса рассчитывает на UTF-8 без BOM. BOM — это три байта EF BB BF в самом начале файла, которые визуально не видны, но для PHP это самый настоящий вывод. Особенно часто это ловят на Windows-редакторах, «Блокноте» и при копировании содержимого через буфер обмена.

Проверить гипотезу можно за секунду — посмотреть первые байты файла:

hexdump -C -n 16 bitrix/modules/main/lib/db/mysqlcommonconnection.php

В выводе важно увидеть, с чего начинается файл. Правильное начало — байты 3c 3f 70 68 70 (<?php). Если перед ними торчит ef bb bf — это BOM, и он и есть причина 500. Любые другие байты перед 3c 3f 70 68 70 — тоже мусор, который нужно убрать.

Чинить нужно в редакторе, который умеет сохранять UTF-8 без BOM — Sublime Text, VS Code, PhpStorm, Notepad++. Открываем файл, ставим курсор в самое начало и удаляем всё, что стоит до <?php (включая пустые строки). В настройках редактора выставляем кодировку «UTF-8» без BOM и сохраняем. После этого фатал уходит, и сайт поднимается без перезапуска PHP.

Но самый правильный путь — вообще не трогать файлы ядра. Если правка всё-таки нужна, восстанавливаем файл из дистрибутива той же версии модуля main, а не правим руками. В mysqlcommonconnection.php нет пользовательской логики — там только низкоуровневая работа с соединением, и любое вмешательство в него ломает ядро при первом же обновлении.

После восстановления бэкапа: Unknown column в запросе к b_user

На ru.stackoverflow разбирали характерный случай: после восстановления резервной копии Битрикс выдаёт MySQL Query Error: SELECT ... FROM b_user U LEFT JOIN b_uts_user BUF ON BUF.VALUE_ID = U.ID ... [[1054] Unknown column 'BUF.UF_SECTIONS' in 'field list']. Сайт открывается, каталог работает, а авторизация или карточка пользователя в админке падает с этой ошибкой. Разбираем, почему так происходит и что с этим делать.

Механика простая: ядро строит запрос к b_user, джойнит его с b_uts_user (таблица значений пользовательских свойств) и в field list указывает колонку UF_SECTIONS. Если колонки в таблице нет, MySQL возвращает ошибку 1054 и запрос отваливается целиком. Причин ровно две: либо бэкап, из которого вы восстанавливались, неполный (в дампе нет b_uts_user или она устаревшая), либо структура на новом сервере другая. Например, вы перенесли только b_user, а таблицу пользовательских свойств не тронули. В проектах с миграциями между серверами мы регулярно видим именно вторую ситуацию: дамп делали «по частям», и b_uts_user отстала от b_user на несколько релизов.

Первым делом смотрим, есть ли вообще такая колонка в базе и где ещё в проекте упоминается UF_SECTIONS:

-- Проверяем, существует ли колонка в таблице значений пользовательских свойств
SHOW COLUMNS
FROM b_uts_user LIKE 'UF_SECTIONS';

-- Смотрим, какие UF-поля реально зарегистрированы для сущности USER

SELECT ID,
       ENTITY_ID,
       FIELD_NAME,
       USER_TYPE_ID,
       MULTIPLE
FROM b_user_field
WHERE ENTITY_ID = 'USER';

-- Ищем следы UF_SECTIONS в структуре таблицы b_uts_user
SHOW
CREATE TABLE b_uts_user;

Дальше два пути, и выбор между ними зависит от того, что у вас в бэкапе. Первый вариант: восстановить b_uts_user из полного дампа, где эта таблица есть вместе с колонкой. Подходит, если у вас действительно есть актуальный полный бэкап и вы готовы перезалить пользовательские свойства целиком. Второй вариант: пересоздать пользовательское свойство UF_SECTIONS через админку: Настройки → Пользовательские поля → Пользователи → Добавить поле. Мы обычно рекомендуем именно этот путь. Битрикс сам сгенерирует колонку в b_uts_user с правильным типом и collation, а заодно пропишет метаданные в b_user_field. При восстановлении из дампа вы рискуете получить рассинхрон между реальной структурой таблицы и записями в b_user_field. Если поле в метаданных есть, а колонки нет, ошибка 1054 вернётся при первом же запросе.

Если поле UF_SECTIONS в проекте больше не используется, не трогайте ни базу, ни админку. Правильнее убрать его из выборки в коде: найдите вызов getList или компонент, который запрашивает это поле, и исключите его из select. Так вы закроете ошибку без изменения схемы данных.

Что проверить перед продом: чеклист по MySQL для Битрикса

Этот чеклист мы прогоняем на каждом проекте перед выкладкой — он экономит часы отладки, когда что-то отваливается уже на боевом. Ничего экзотического: только то, что реально ломает Битрикс и всплывает в первые же сутки после релиза.

Большинство пунктов проверяются за пять минут. Но именно они закрывают 80% инцидентов, которые потом ищут по логам всю ночь. Прогоняем в связке: сначала конфиги сервера, потом файлы подключения, потом админка — и только после этого катим.

• MySQL версии 8.0 и выше — актуальное требование вендора.
• innodb_strict_mode=OFF в [mysqld] — иначе «Режим работы MySQL» не позеленеет.
• sql_mode пустой — значение NO_ENGINE_SUBSTITUTION даёт критичную ошибку и блокировку запросов.
• max_allowed_packet=1024M — иначе крупные выгрузки из 1С рвутся на полпути.
• sync_binlog=0 — стандарт для BitrixVM, снижает накладные расходы на запись.
• thread_pool_size=16 — дефолт, если параметр вообще не задан в конфигах.
• Оба файла подключения синхронизированы: dbconn.php и .settings.php.
• Плашка «Режим работы MySQL» в админке — зелёная.
• В файлах ядра нет BOM — код начинается строго с <?php.
• Бэкап снят и проверен на рестор — не просто «файл лежит».

Если пункт про зелёную плашку не выполнен — не катим. Лучше задержать релиз на день и спокойно довести конфиги, чем ловить 500 в час пик на живых заказах. Разница между «потерпели сутки» и «потеряли выручку за вечер» обычно не в пользу второго, и мы это видели не раз. Плашка — агрегированный индикатор: она загорается красным, если хотя бы один из параметров вроде innodb_strict_mode или sql_mode не соответствует ожиданиям ядра.

Для каталогов 20k+ SKU отдельно проверяем innodb_buffer_pool_size — дефолтные 128M не вытянут обмен с 1С. При активном импорте InnoDB постоянно перечитывает страницы с диска, и время обмена растёт нелинейно: чем больше SKU, тем хуже.

Под такой объём пул обычно поднимают до 1–2 ГБ, ориентируясь на доступную RAM сервера. Точную цифру подбирают по SHOW ENGINE INNODB STATUS — там видно Buffer pool hit rate. Если он ниже 99% при обмене — памяти мало, и это первое, что стоит увеличить.

Читайте также: Как обновить 1С-Битрикс: ядро, модули и обмен с 1С без сюрпризов, Как ускорить Битрикс: композит, кэширование и настройка сервера.

Подробнее об услуге: поддержка и сопровождение сайтов на Битрикс.