Как ускорить тупой запрос 1С в миллион раз без правок кода
Иногда в 1С прилетает “невинный” SQL, который внезапно начинает жечь прод: запрос выполняется 45 секунд, и таких - сотни раз в день 😬
Кейс из практики на Postgres (Tantor XData): нашли в топе долгих запросов вот такую красоту:
SELECT min(_period)
FROM _accumrg93090
WHERE _fld3457 = 0
AND _recordertref = ...
AND _recorderrref = ...
HAVING NOT min(_period) IS NULL;
🧠 Что происходило в 1С
Регламентное задание удаляло помеченные объекты, а БСП перед удалением делала стандартную проверку “Даты запрета изменений” - ищет минимальную дату движения документа по регистру накопления.
📉 Почему так медленно
Планировщик выбирал не тот индекс и делал огромный Index Only Scan, потому что статистика по полю _recorderrref была очень неточной (распределение “длинный хвост”: большинство регистраторов мелкие, но есть «тяжеловесы» на сотни тысяч строк).
В таблице:
• 761 млн строк
• _recorderrref ≈ 2.35 млн уникальных
• но планировщик “видел” всего 123 тыс 🤡
✅ Фикс без правки кода 1С - улучшили статистику точечно
В Tantor Postgres есть параметр STATMULTIPLIER, который увеличивает объём выборки для ANALYZE по конкретной колонке:
alter table _accumrg93090
alter column _RecorderRRef SET STATMULTIPLIER 15;
После пересчёта статистики план поменялся на правильный индекс (_accumrg93090_2), и время выполнения запроса стало… 0.017 ms 😳
🔥 Итог: ускорение примерно в 1 000 000 раз.
💡 Вывод для 1С-админов/DBA
Если на Postgres 1С внезапно “втыкает” на seemingly простых запросах, проверь:
• выбор индекса,
• актуальность статистики,
• перекос распределения по ссылочным полям (_recorderrref, _recordertref).
И да, иногда можно спасти производительность настройкой статистики, не трогая ни модуль 1С, ни БСП.
📌 Ссылка на статью: https://habr.com/ru/companies/tantor/articles/985130/
#1C #PostgreSQL #DBA #performance #оптимизация #БСП
✍️ @odin1C_rus