Масове видалення товарів 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

Якщо ви зіткнулися з необхідністю масового видалення товарів, отримайте консультацію — ми підберемо ефективну стратегію для вашого каталогу.