В ИЕРАРХИИ #674387

Слышал ранее, что в 1С8 конструкция запросов "В ИЕРАРХИИ" работает очень  не оптимально. Из анализа SQL трассировок - видел, что такие конструкции порождают создание временные таблицы (причём целый набор) и уже их объединённый результата далее подставляется в SQL оператор "IN". Соответственно, если в запросе будет несколько таких условий, то он будет   существенно замедлен. А если будет несколько условий над одним и теми же полями - то они никак не будут оптимизированы - для каждого будут созданы отдельные наборы временных таблиц и отдельные выборки. Причём в запросах по бухгалтерским регистрам такие конструкции бывают очень частыми и в очень большом количестве для отбора по иерархии счетов. Вот и мой вопрос - действительно ли всё так плохо и не эффективно? И стоит ли проводить существенную оптимизацию запросов, в которых содержится целый ворох условий вида "В ИЕРАРХИИ" или сейчас платформа 1С 8 (пока понимаем последний релиз редакции 8.2) более менее эффективно справляется с такими конструкциями и нет особого смысла тут что-то накручивать? Особенно если речь идёт об запросах, используемых в отчетах?

1с их сама тихой сапой оптимизирует ... так чтоне замарачивайся ... ну или используй пакеты

Работает - не трогай

дасистак

Очевидно же. Не устраивает скорость - надо что-то делать. Устраивает, не надо.

В чём заключается оптимизация? Работает... но не шибко быстро

да. В иерархии работает медленно. Делал проверку в записи контрагента - запрос по 1 элементу выполнялся 1 сек и больше. Сейчас запрос по конт. инф. с иерархией работает медленно

Ну, скорость никогда не устраивает, и никогда не будет устраивать. А анализировать - насколько велик вклад таких конструкций в общее замедление - не просто. Просто хотелось бы что-то сделать на глобальном уровне архитектуры плана счетов и отказаться от использования таких конструкций (в большинстве своём) без существеннгых переделок имеющихся запросов.

Проблема резко усугубляется когда в запросе становится  много таких условий.

При исполнении запроса, для всех условий В ИЕРАРХИИ с одинаковым значением параметра, формируется одна временная таблица на один пакетный запрос. Оптимизирована работа запроса, при использовании конструкции В ИЕРАРХИИ. Оптимизирована работа системы компоновки данных с источником данных в виде запроса, при использовании конструкций В ГРУППЕ и В ГРУППЕ ИЗ СПИСКА.

Вот, например, простой запрос с большим количеством конструкций "В ИЕРАРХИИ". Можно сказать, ЧТО ЭТО ЧАСТЬ большого запроса, где подобных вставок очень многого (и не обязательно в конструкции "ВЫБОР"). И пакетные запросы тут не особо спасают (ну только если их специально переписывать, чтобы минимизировать такие выборки "В ИЕРАРХИИ")     ВЫБОР     КОГДА Счет В ИЕРАРХИИ(ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.РасчетыСПоставщикамиИПодрядчиками))     ВЫБОР     КОГДА Счет В ИЕРАРХИИ(ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.РасчетыСПокупателямиИЗаказчиками))     ВЫБОР     КОГДА Счет В ИЕРАРХИИ(ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.РасчетыСРазнымиДебиторамиИКредиторами))     ВЫБОР     КОГДА Счет В ИЕРАРХИИ(ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.РасчетыСПерсоналомПоОплатеТруда))     ВЫБОР     КОГДА Счет В ИЕРАРХИИ(ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.РасчетыСПодотчетнымиЛицами_))                              ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.РасчетыСПерсоналомПоПрочимОперациям))             И Счет НЕ В ИЕРАРХИИ(&Исключение))

пакетный улутшит производительность данного на порядок ...

Насколько эффективно будет сделана такая замена, если запрос ссоставной и такие конструкции будут разбросаны по разным под запросам, в т.ч. частям пакета? Вот я и говорю, конечно даннйы запрос можно существенно улучить - существенно его переписав. Был вопрос - стоит ли вообще городить эту оптимизацию? Причём мне не очень хотется переписывать соьтни запросов на совершенно новую архитектуру. Мне хочется - модернизировать несильно план счетов ;)

ну если раньше скул при выполнении твоего запроса городил, в темпдиби, что-то около 6 таблиц и потом их селектил ... то сейчас таблица будет одна ... думаю должно повысить существенно

То есть, гордиться ручную оптимизацию смысла большого нет?

поставь последнию версию и сравни ... только незабудь отказаться от поддержки предыдущих версий

а можно примерчик, как оптимизировать такое: ВЫбрать Ссылка из Справочник.Номенклатура ГДЕ Ссылка в ИЕРАРХИИ(&ВыбГруппа)

+ что и требовалось доказать, одни блаблабла :)

ты чего так долго ждал ... целых 8 минут

Речь не идёт об оптимизации всего и вся, особенно простых или слишком универсальных конструкций. Приведённый в запрос нельзя оптимизировать, если конечно нет каких-либо особых и не сказанных ограничивающих "условий" или эта оптимизация не превращается в экстремальную, с хешированием и т.п. хренью

ну как, дал время на подготовку канешн... почему нельзя? а это: ВЫбрать Ссылка из Справочник.Номенклатура ГДЕ Ссылка = Номенклатура1 ИЛИ Ссылка = Номенклатура3 ...

ИЛИ 1с не советует использовать в условиях...

Вот это и есть те самые особые "условия" Вам же как-то нужно определить эти самые "Номенклатура1..3" (это параметры? Вы не указали символ "&"). Это конечный набор? Каков его размер? Вы будет проводить оптимизацию разных размеров этого набора? Тут много - очень много особых условий возникает. Он не были Вами озвучены в задаче оптимизации!

Но почему? вРОДЕ sql НЕПЛОХО ИХ ОТРАБАТЫВАЕТ, когда их количество не превышает все разумные пределы ;)

ИМХО, 1-вый вариант лучше, чем второй 1. ВЫБРАТЬ Ссылка 2. ВЫБРАТЬ Ссылка ИЗ Справочник.Номенклатура ГДЕ Ссылка В(Номенклатура1,              Номенклатура2,              Номенклатура3)

Патамучта 1с не рекомендует :-) Типа индексы не будут использоваться. 1. Не следует использовать ИЛИ в секции ГДЕ запроса. Это может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, что увеличит время работы запроса и вероятность возникновения блокировок. Вместо этого следует разбить один запрос на несколько и объединить результаты. 2. Не рекомендуется использовать логическое ИЛИ в условиях соединения, то есть в секции ПО запроса. Это так же может привести к выбору неоптимального плана и медленной работе запроса. Простого универсального способа переписать такой запрос без использования ИЛИ не существует. Следует проанализировать решаемую задачу и попытаться найти другой алгоритм ее решения. 3. Если в конфигурации описано несколько ролей с разным ограничением доступа на уровне записей (RLS), то не следует назначать одному пользователю более одной такой роли. Если один пользователь будет включен, например, в две роли с RLS - бухгалтер и кадровик, то при выполнении всех его запросов к их условиям будут добавляться условия обоих RLS с использованием логического ИЛИ. Таким образом, даже если в исходном запросе нет условия ИЛИ, оно появится там после добавления условий RLS. Такой запрос так же может выполняться неоптимально - медленно и с избыточными блокировками.   Вместо этого следует: Пересмотреть состав ролей таким образом, чтобы к одному объекту метаданных давала доступ только одна роль (на чтение, запись и т.п.); При необходимости разработки нескольких ролей, предоставляющих доступ к одному объекту метаданных, задавать в них одинаковые условия RLS. В этом случае к тексту запроса будет добавлено только одно условие, без объединения по ИЛИ; Либо если это допустимо с точки зрения прикладной области, создать "смешанную" роль - "бухгалтер-кадровик" и прописать ее RLS таким образом, чтобы избежать использования ИЛИ в условии, а пользователя включить в эту одну роль.

ну не указал "&" - мне и в пофигураторе хватает этого ...вечно приходится переключаться блин зы: кста, кто как оптимизирует надбор этого "&" pps: пунтосвитчер на сервер - не предлагать :)

Надо будет потестить ;) ALT+3 8 на цифровой клаве - в любой раскладке и состоянии NumLock (правда последний лучше включать - не все приложения на все клавиши будут адекватно реагировать) А так же полезны ALT+6 0 и ALT+6 2 для < > соответсвенно

спасибо,  надо запомнить

раскладка клавиатуры от Чистова рулит

Ну запомни ещё ALT+1 6 ALT+1 7 ALT+2 2 ALT+2 6 и т.д. ну и ALT+1 ALT+2 ALT+3 ...

а где в коде используется ALT+16 к примеру?

А почему сразу в коде? Хот, например, в комментарии к коду можно ;) Или в описании инструкций - я люблю этот символ для разграничении пунктов меню ;)

не надо мне там, ограничемся благодарностями за ;)

А ALT+2 0 - показывает путь к доступу к секретным функциям 1С (Привет "СЕТЬ").

Какой же Вы скупой на благодарности - лишнюю благодарность  прибережёте ;)

В соответствие с данной рекомендацией получается, что имеет смысл переписать вот так 3. ВЫБРАТЬ Ссылка И, соответственно, это 3-тий вариант будет более оптимален по производительности?

ну так что будет быстрее и эффективнее?

А проверить?

Конечно - это всегда можно - но качественный эксперимент требует больших усилий. Пока пытаюсь ограничиться мнениями компетентных людей, желательно уже прошедших через это!