Не сохраняются разделы и свойства товаров в 1С-Битрикс. Причина оказалась в переполнении ID инфоблока

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

На первый взгляд проблема выглядела как ошибка в обработчиках событий или кастомизации сайта. Однако причина оказалась гораздо глубже и связана с ограничениями структуры базы данных.

Симптомы проблемы

На сайте наблюдались следующие признаки:

  • товар сохранялся без ошибок;

  • выбранный раздел каталога не сохранялся;

  • некоторые свойства товара сбрасывались после сохранения;

  • проверка системы Битрикс показывала ошибки структуры базы данных;

  • в журнале появлялись сообщения о невозможности выполнить SQL-запросы.

При этом количество записей в таблице элементов инфоблока превышало 160 000, поэтому первоначально проблема не выглядела связанной с объемом данных.

Что показала диагностика

Во время проверки структуры базы данных Битрикс отображал предупреждения:

В таблице b_iblock_element поле ID не соответствует описанию на диске

В таблице b_iblock_section поле ID не соответствует описанию на диске

Попытка выполнить рекомендованный системой запрос:

ALTER TABLE b_iblock_element

MODIFY ID INT NOT NULL AUTO_INCREMENT;

завершалась ошибкой:

Mysql query error: (1062)

ALTER TABLE causes auto_increment resequencing,

resulting in duplicate entry '2147483647'

for key 'PRIMARY'

На этом этапе стало понятно, что проблема связана не с логикой сайта, а с ограничением типа данных.

Причина ошибки

В стандартной установке Битрикс поле ID в таблице b_iblock_element имеет тип:

INT

Максимальное значение для знакового INT:

2 147 483 647

На данном проекте количество элементов и операций за годы работы привело к тому, что идентификаторы превысили этот предел.

Фактически в таблице уже существовали записи вида:

2147483651

2147483655

2147502301

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

Ранее кто-то уже изменил поле ID на тип:

BIGINT

что позволило продолжить создание новых элементов.

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

Почему перестала работать привязка к разделам

При сохранении элемента Битрикс выполняет запрос в таблицу связей:

b_iblock_section_element

Пример запроса:

INSERT INTO b_iblock_section_element

(

    IBLOCK_SECTION_ID,

    IBLOCK_ELEMENT_ID

)

SELECT

    S.ID,

    E.ID

FROM

    b_iblock_section S,

    b_iblock_element E

WHERE

    S.ID IN (87)

    AND E.ID = 2147483655

Но поле:

IBLOCK_ELEMENT_ID

в таблице связей продолжало иметь тип:

INT

Из-за этого значение:

2147483655

не помещалось в поле, и связь с разделом просто не сохранялась.

Внешне это выглядело как обычная ошибка привязки элемента к разделу.

Решение

После анализа специалисты технической поддержки подтвердили причину проблемы.

Была выполнена модернизация структуры базы данных:

  • изменены типы полей в связанных таблицах;

  • поля, содержащие идентификаторы элементов инфоблоков, переведены на тип BIGINT;

  • синхронизирована структура таблиц, работающих с b_iblock_element.

После внесения изменений:

  • привязка товаров к разделам начала работать корректно;

  • свойства товаров стали сохраняться без потерь;

  • система смогла работать с элементами, имеющими ID больше 2 147 483 647.

Важный вывод для владельцев крупных проектов

Если проект существует много лет и активно использует инфоблоки, обязательно проверьте:

SELECT MAX(ID)

FROM b_iblock_element;

Если значение приближается к:

2147483647

необходимо заранее планировать перевод связанных таблиц на тип BIGINT.

Иначе проблемы могут проявляться в самых неожиданных местах:

  • не сохраняются разделы каталога;

  • теряются свойства товаров;

  • появляются ошибки при работе с инфоблоками;

  • возникают сбои в административной части сайта.

Итог

В данном случае проблема была не в коде сайта, не в обработчиках событий и не в настройках Битрикс. Причиной стало достижение предельного значения типа INT для идентификаторов элементов инфоблока.

После перевода связанных таблиц на BIGINT работоспособность каталога была полностью восстановлена.

Этот кейс хорошо показывает, что на крупных проектах необходимо регулярно контролировать структуру базы данных и учитывать ограничения используемых типов данных.