Быстрая вставка в MySQL для базы 1С‑Битрикс

Зачем это в связке с Битриксом

Каталог, обмены, агенты и кастомные скрипты часто сводятся к тысячам одиночных INSERT в InnoDB. Узкое место — не сам факт записи строки, а число кругов «клиент ↔ сервер», разбор запроса и сброс журнала транзакций. Ниже — практики под современный MySQL/MariaDB и типовую схему Битрикса, без опор на MyISAM и удалённые ветви синтаксиса.

Не опирайтесь на INSERT DELAYED и «низкий приоритет»

INSERT DELAYED для таблиц MyISAM удалён в MySQL 5.7+; для InnoDB он и не был полноценной заменой обычной вставки. INSERT LOW_PRIORITY остаётся нишей MyISAM и не поможет в типовом проекте, где сущности — на InnoDB. Если в старых заметках вы ещё видите эти конструкции, перепишите план под пакеты и транзакции.

Группируйте строки в один INSERT

Вместо ста запросов вида INSERT INTO t (a,b) VALUES (1,'x') используйте INSERT INTO t (a,b) VALUES (1,'x'),(2,'y'),…. Сокращается доля времени на разбор и обход оптимизатора на каждую строку; на нагрузочных импортах выигрыш измеряется кратно. Разумный порог длины пакета ограничивают размером пакета max_allowed_packet и памятью — при необходимости режьте по 500–5000 строк и меряйте на копии базы.

Транзакции вместо потока autocommit

Для InnoDB оберните серию вставок в START TRANSACTION … COMMIT: меньше fsync-операций на малых пакетах и предсказуемее откат при ошибке. Это ближе по смыслу к старому совету «сначала все INSERT, потом один сброс буфера», но без блокировки всей таблицы уровня MyISAM.

LOCK TABLES и MyISAM — не ваша модель

Паттерн «LOCK TABLES, много вставок, UNLOCK» уместен для MyISAM и журналов на нём. В Битриксе рабочие данные — в InnoDB; глобальная блокировка мешает параллельным витринам и сессиям. Для массовой загрузки с допуском чтения из других потоков ориентируйтесь на батчи в транзакциях и нормальные индексы, а не на LOCK TABLES.

Вставка и обновление без лишнего SELECT

Если нужно «вставить, а если ключ уже есть — обновить поля», используйте INSERT … ON DUPLICATE KEY UPDATE (или отдельная логика с уникальным ключом), чтобы не делать предварительный SELECT на каждую сущность. Так проще удерживать конкуренцию и сократить число запросов из PHP-агентов и обменов.

Про индексы и DELAY_KEY_WRITE

DELAY_KEY_WRITE=1 и отложенная запись индексов — про MyISAM. На InnoDB ключи обновляются в транзакционной модели; «ускорение за счёт отложенной записи индексов» из старых рецептов сюда не переносится напрямую. Если после массового импорта вторичные индексы мешают — обсуждайте отдельно порядок загрузки, отключение проверок на время сеанса (осторожно) или ALGORITHM=INPLACE для индексов на пустых таблицах, но не смешивайте это с устаревшими флагами MyISAM.

Итог

Для базы под 1С‑Битрикс ориентируйтесь на InnoDB, многострочные INSERT, транзакции батчами и ON DUPLICATE KEY UPDATE там, где справедливо. Так вы убираете мёртвые приёмы эпохи MyISAM и снижаете нагрузку на тот же инстанс, где крутятся инфоблоки и заказы.

-- Пакет в одном запросе
INSERT INTO my_stats (site_id, day_key, hits)
VALUES
  (1, 20250501, 3),
  (1, 20250502, 7);

-- Транзакция для пачки вставок (InnoDB)
START TRANSACTION;
INSERT INTO my_import_staging (ext_id, payload) VALUES ('a','{}'), ('b','{}');
COMMIT;

-- Вставка или обновление по уникальному ключу
INSERT INTO my_map (code, name)
VALUES ('SKU-1', 'Товар')
ON DUPLICATE KEY UPDATE name = VALUES(name);