#SQL Катастрофическое падение скорости при обновлении — 29 апреля 2026 г. в 02:41:22.847
#SQL Катастрофическое падение скорости при обновлении В последнее время флагманские конфигурации 1С выпустили достаточно «тяжёлые» обновления ERP, УХ, KA и т.д. Особенностью этих обновлений, помимо большого количества реструктуризаций объектов так же является большое количество монопольных обработчиков после обновления (это когда идёт «градусник» в пользовательском режиме) и вход в 1С заблокирован. Мы в рамках инцидентов РКЛ уже несколько раз столкнулись с тем, что процесс этого монопольного обновления затягивается на несколько часов или даже суток! Систематизация проблемы показала, что она существует только при использовании MS SQL и при этом полностью отсутствует на PostgreSQL и там этот этап проходит буквально за минуты. Дальнейший анализ показал, что проблема возникает не всегда и не у всех – что с одной стороны сильно затрудняет её решение (так как по классике – такая же нога и не болит), с другой стороны есть что с чем сравнить (тех у кого быстро и тех у кого медленно, при сопоставимом количестве записей в регистрах – чтобы ощутить проблему, этих записей должны быть миллионы и десятки миллионов). Разбор процедур обработчика показал, что происходит регистрация к изменению всех строк определённых регистров для дальнейшей постобработки в фоновом режиме, когда вход пользователей уже возможен, но функционал может быть ограничен. Тонкость регистрации изменений состоит в том, что сначала проверяется есть ли уже такие зарегистрированные изменения (на уровне СУБД это запрос SELECT), и если таковых нет, то происходит уже сама регистрация (на уровне СУБД это запрос INSERT). И по Технологическому журналу 1С мы получали чудовищную деградацию скорости именно при SELECT, если по началу он длился тысячные доли секунды, то затем вырастал до десятков секунд. Разбор плана запроса показал что статистика чудовищно ошибается в предположении сколько строк уже зарегистрировано, например статистика предполагает что их 638 шт, а по факту оказывается 3 564 175 шт. А у тех у кого обновление было быстрым – статистика не ошибалась… В итоге было обнаружено, что всему виной отключенный Автоматический расчёт статистики на базе (аналог autovacuum_analyze в PostgreSQL) – на картинке видно где это включается. Причина отключения достаточно известна – есть прекрасная статья, конкретно отключение автообновление статистики начинается с заголовка «Нестандартные ожидания на блокировках». Что делать? ❗Выключать автообновление статистики нужно только если вы фиксируете ожидания с типом LCK_M_SCH_S. Придётся теперь следить и за этим параметром, и включать автоматический расчёт статистики, если вы ожидаете огромный объём регистрации к изменению. Ну а при обновлении конфигурации – нужно включать автоматический расчёт на постоянной основе, просто как часть процесса и только после окончании всех процессов обновления, в том числе и фоновых уже выключать автообновление статистики, если на вашей базе это необходимо.