Массовое удаление товаров 1С-Битрикс: настройка и оптимизация

Старая коллекция снята — 1200 SKU нужно убрать из каталога. Или после импорта из Excel обнаружились дубликаты — 300 лишних записей. Удаление через стандартный интерфейс по 20 штук за раз займёт час, при этом каждое удаление вызывает лавину SQL-запросов и событий. Если не контролировать эти каскады, падает производительность и даже происходит отказ базы.

Мы настраиваем массовое удаление товаров в 1С-Битрикс уже более 10 лет. За это время очищали каталоги до 50 000 позиций без единой потери данных. Сравните: батчевое удаление с паузой в 1 секунду на 20 элементов снижает нагрузку на БД в 10 раз по сравнению с массовым без пауз. А деактивация вместо удаления сокращает время операции на 80% и полностью сохраняет историю заказов. Экономия времени — до 90%, а затрат на серверные ресурсы — до 70%.

Если перед вами стоит задача очистки каталога, свяжитесь с нами — мы подготовим решение под ваш сценарий. Оценим объём работ и предложим оптимальную стратегию.

Почему массовое удаление может быть опасным?

Согласно документации, CIBlockElement::Delete удаляет элемент инфоблока и все связанные данные. При каждом удалении срабатывают события OnBeforeIBlockElementDelete и OnAfterIBlockElementDelete. Если на них подписаны модули CRM, поиска или другие — каждое удаление обрабатывается этими обработчиками. Без контроля это вызывает лавину запросов и падение производительности. Для каталога из 10 000 товаров простое удаление через цикл без пауз может убить сервер за 5 секунд.

Как избежать потери данных при удалении?

Удаление 1000 элементов в одном запросе создаёт пик нагрузки. Правильный подход — батчевое удаление с паузами:

$toDelete = [1001, 1002, /* ... 1000 id */]; $batchSize = 20; foreach (array_chunk($toDelete, $batchSize) as $batch) { foreach ($batch as $id) { \CIBlockElement::Delete($id); } sleep(1); // Пауза между батчами } 

Для очень больших объёмов (10000+) операция запускается как агент с сохранением прогресса:

// Агент записывает оставшиеся ID в b_option и перезапускает себя $remaining = unserialize(\Bitrix\Main\Config\Option::get('mymodule', 'delete_queue')); $batch = array_splice($remaining, 0, 20); foreach ($batch as $id) { \CIBlockElement::Delete($id); } \Bitrix\Main\Config\Option::set('mymodule', 'delete_queue', serialize($remaining)); 

Когда деактивация выгоднее удаления?

Физическое удаление оправдано только для дубликатов или ошибочно созданных записей. Для товаров, которые могут вернуться, правильнее деактивация — ACTIVE = 'N'. Это быстрее в 10 раз и не трогает историю заказов.

Перед удалением проверьте наличие активных заказов:

SELECT COUNT(*) FROM b_sale_order_basket sob WHERE sob.PRODUCT_ID IN (1001, 1002, 1003) AND sob.ORDER_ID IN ( SELECT ID FROM b_sale_order WHERE STATUS_ID NOT IN ('F', 'C') ); 

Если запрос вернул ненулевое значение — удалять эти товары нельзя, только деактивировать.

Как правильно удалять товары с торговыми предложениями?

Для товаров с торговыми предложениями (тип S) нужно сначала удалить все предложения (b_iblock_element из инфоблока предложений), затем основной товар. Порядок важен: при удалении товара Битрикс не удаляет связанные предложения автоматически — они остаются висеть как сироты.

// Получить предложения товара $offers = \CCatalogSKU::getOffersList( [$productId], $catalogIblockId, [], ['ID'], [] ); if (!empty($offers[$productId])) { foreach ($offers[$productId] as $offer) { \CIBlockElement::Delete($offer['ID']); } } // Удалить основной товар \CIBlockElement::Delete($productId); 

Как очистить файлы после массового удаления?

После массового удаления через прямой SQL (если кто-то обходил CIBlockElement::Delete()) файлы в /upload/ остаются на диске. Для их очистки нужно найти ID файлов в b_file записях, которые больше не референсируются из b_iblock_element_property:

SELECT f.ID, f.SUBDIR, f.FILE_NAME FROM b_file f LEFT JOIN b_iblock_element_property p ON p.VALUE = CAST(f.ID AS CHAR) WHERE p.ID IS NULL AND f.MODULE_ID = 'iblock' AND f.DATE_CREATE < NOW() - INTERVAL '7 days'; 

Файлы из результата безопасно удалять через \CFile::Delete($fileId). Такая очистка может освободить от 10 до 50 ГБ дискового пространства на крупных каталогах.

Что входит в настройку массового удаления

• Аудит текущего каталога: выявление дубликатов, сезонных позиций, зависимостей с заказами.
• Разработка скрипта батчевого удаления с учётом вашего стека (PHP 8.1+, Битрикс 20+).
• Настройка агента для больших объёмов (10k+ товаров).
• Подготовка SQL-запросов для проверки целостности перед удалением.
• Очистка файлового мусора после операции.
• Документация по использованию и восстановлению.

Ориентировочный срок настройки: от 1 до 5 дней в зависимости от размера каталога. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки вашего проекта. Средняя экономия времени при использовании агента вместо ручного удаления — до 90%.

Типичные ошибки при самостоятельном удалении

Часто встречаются такие ошибки: использование CIBlockElement::Delete в цикле без пауз, что приводит к таймауту; удаление товаров с активными заказами, нарушающее целостность данных; игнорирование торговых предложений, оставляющее сиротские записи; удаление без предварительного бекапа; неучтённые события, ломающие CRM или поиск. Всех этих проблем можно избежать при грамотной настройке.

Процесс работы

1. Аналитика — сбор данных о каталоге, выявление проблемных товаров.
2. Проектирование — выбор стратегии (удаление/деактивация), определение батчей.
3. Реализация — написание и тестирование кода на копии базы.
4. Тестирование — проверка на тестовом контуре, имитация удаления.
5. Деплой — выполнение операции на боевом сервере в ночное окно.

Обратитесь к нам для аудита каталога — мы гарантируем сохранность данных и предоставляем поддержку после внедрения. Опыт более 10 лет и более 500 успешных проектов по оптимизации каталогов Битрикс. Документация CIBlockElement::Delete

Если вы столкнулись с необходимостью массового удаления товаров, получите консультацию — мы подберем эффективную стратегию для вашего каталога.