Исследования показали, что 1сный ДБФный движок при исполнении чорного-пречорного запроса не использует никакие индексы. То есть тупо в случае необходимости получения подмножества записей из справочника (фильтр наложен в Условие())- будут движком прочитаны ВСЕ записи справочника, и к каждой записи справочника применены условия. Прошедшие условие(я) - попадут в рабочую выборку как результат запроса.
Всё.

А прямые запросы не потому быстрые что они прямые, а потому что юзают индексы.

Поэтому (наверное, не всегда), если есть возможность получить подмножество по индексируемому полю, то следует юзать
- ВыбратьПоРеквизиту(ИмяРеквизита,ЗначениеРеквизита) для фильтра на равенство
- ПорядокРеквизита(ИмяРеквизита)+ОбратныйПорядок() если надо - для реализации выборки "от-до"

Я подозревал, что в чорных запросах на ДБФ версии не все хорошо, но чтобы так...

Как жесток этот мир.

понятно что в (0) - для тех кто писал внутренности 1С++ и ковырялся в движке - ничего нового, но для остальных - может кому-то поможет

А что ей ещё пользуюстся?

План выполнения надо смотреть и в прямых, не факт что там не scan :)
А чисто по времени? Наложить просто на = условие, потом убрать галочку сортировка и снова запустить? Что-то сомневаюсь что так плохо

Чорные запросы и в sql-версии часто ведут себя неадекватно, тупо перекачивая всю таблицу в каталог временных файлов в виде dbf, с последующей обработкой. Нафиг они нужны вообще.

(4) "тупо перекачивая всю таблицу в каталог временных файлов в виде dbf, с последующей обработкой."
- такая хрень может быть при использовании конструкций "Когда" и еще в некоторыз случаях

(3) именно так, "плохо"
все "сортировки"/индексы - юзаются только на Операторах языка. внутри запросов тупо чтение "записей" запроса (зависит от точек и упоминаемых обектов в запросе) и фильтрация их по условиям

даже если запись например справочника суммарная длина = 500 символов, а в запросе тебе всего два поля нужны - суммарная длина 30 символов - будет считана _вся_ запись, 500 сивмолов.

(2) изыди, раскольник

(2) А что уже 8-ка высохла? Можно смотреть?

(0)На сколько я помню из черных запросов по справочнику данные всегда возвращаются упорядоченные по наименование или даже в иерарахии. Так что тут используется индекс этого самого наименования. Такой же план скорей всего и sql-сервер бы сделал.

(9) вряд ли. это тупо выборка идет не по физической таблице, а, возможно, по ключу основного (первого?) индекса. Но это не значит что этот индекс как-то участвует в селекции данных.

(0) Некрофил...

(0) > Исследования показали, что 1сный ДБФный движок при исполнении чЁрного-пречЁрного запроса не использует никакие индексы.

То, что родные запросы 1С77 ни в пикантное место, ни даже в импозантное, я понял сразу, как начал программировать собственную «зарплату» на «семерке». Потестил те же самые запросы через движок Visual FoxPro, оказалась, что они выполняются в 15 раз быстрее. После этого я просто забыл, как делаются внутренние запросы в 1С, и использую исключительно внешние.

Правда, когда движок Фокс-Про считает мою «зарплату» (обращаясь к 1С77 как к DDE-серверу), он подключается к индексам, которая генерит «семерка». Но для большей эффективности стоит создавать все индексы на стороне VFP.

Теперь, когда делаю новую версию своей «зарплаты», я решил отказаться от VFP и использоваться SQLite, через собственную внешнюю компоненту. А весь расчет делать в памяти (т.е., проецирую всю БД в память). Вполне логично возникает вопрос, а почему бы всю бизнес логику не вынести во внешнюю компоненту?

Это дает массу преимуществ. Главное то, что можно сделать ОДНУ такую ВК и для «семерки» и для «толстых» форм «восьмерки». Дублирование базы данных 1С в формате SQLite позволит повысить надежность хранения этих данных. Можно также все внешние скрипты SQLite хранить снаружи. Бинарный формат компоненты упрощает защиту бизнес логики от постороннего вмешательства. Ну и т.д. и т.п.

Кстати, полностью отказаться от внутренних запросов в 1С77 мне помогают такие фишки, как:

– Собственное проведение псевдо-документов (реализованных на справочниках).
– Эффективное использование групп в справочниках (это самая крутая фича в 1С, на мой взгляд).
– Предвычисления (например, заранее посчитать «средние»).
– Промежуточные данные (например, в ТЗ).

В итоге, даже самые сложные отчеты (на тысячу человек) выполняются за секунды. Расчет тысячи человек идет меньше часа. При этом внутренних запросов 1С77 у меня нет от слова «совсем».

С SQLite, думаю, дела у меня будут идти еще быстрее. А 1С используется только как «интерфейсный контейнер».

(0) Сергей, чОрные запросы в клюшках надо уже лет 10 забыть как страшный сон. кроме медлительности - они неудобны и нелогичны.
за 10 лет на предыдущем месте чОрными не пользовался совсем. даже то, что делается штатным конструктором - быстрее было написать в консоли (не говоря уж о конструкторе прямых запросов).

(0)
О сколько нам открытий чудных
Готовят просвещенья дух
И опыт, сын ошибок трудных,
И гений, парадоксов друг,
И случай, бог изобретатель.
А. С. Пушкин.
1829 год.
Ничего не меняется :)

(14) намекаешь на то, что пора заканчивать откапывать стюардессу?

(15) Про стюардессу - подробнее...

(16) https://otvet.mail.ru/question/77583497

(17) О! Месье! Понимает толк... :))))))))))))))))

(18) отож. анекдота есть разные варианты. но смысл одинаков...
Посвящать время самостоятельным исследованиям клюшек в конце 2018 года - это как раз то, в чем по вашему выражению "мусье понимают толк".
все давно исследовано. стркутуры данных исследованы и известны. механизмы ихх работы тоже. (конкретно черные запросы исследовал , емнип, WildHare году в 2002-2003) инструменты придуманы, отлажены, отработаны, широко использовались, и многими уже выкинуты. Если уж так все шоколадно отлажено - ну добавить еще одну компоненту, и нормально писать нормальными запросами, на нормальном диалекте t-sql.

(12) а чем тебя не устраивает текущая 1SQlite ВК ...? которая делает все хорошо? зачем свою?

(19) когда есть проблемы с быстродействием - тогда и юзаем прямые. а таких задач у меня не шибко много блыо.

А подскажите кто, что делает галка "Отбор" в реквизитах справочника (ну крпоме того что она там есть, а то я знаю вас шутников). Какой от нее профит?

(21) прямые - они удобнее. И прямее. Ну и быстрее, конечно. Плюс есть скалярные - иногда не хватает в снеговике (хотя может они там и есть, а я плохо искал)
(22) добавляет индекс, и возможность использования НайтиПоРеквизиту()

(23) "добавляет индекс, и возможность использования НайтиПоРеквизиту()"
- а что делает галка "Сортировка" тогда?

(23) "добавляет индекс, и возможность использования НайтиПоРеквизиту()"
- сильно сомневаюсь. Для "найти по реквизиту" достаточно галка "Сортировка"

Если на реквизите стоит галка "сортировка" - то получается индекс по указанному реквизиту, если стоит галка "отбор" то в индех добавляется "код" или "наименование" (в зависимости от основного представления)

SP6893 и SP6894 - два однотипных реквизита, на SP6893 - стоит только "Сортировка" (недоступен интерактивный отбор юзером) на SP6894 - "сортировка+отбор", доступен интеактивный отбор юзером.

I=VI6893   |VI6893        |0     |SP6893                                                      |VI6893    
I=VI6894   |VI6894        |0     |SP6894,CODE(UPPER)                                          |VI6894

В том же СП (продавать мне не надо, я наше ;-) - "сортировка" упоминается исключительно в общих методах справочника.
а "отбор" - только в методах, имеющих отношение в визуальным формам. Так что, в общем, если не планируется использование отборов в визуальных формах - то "отбор" можно отключить.

ну и если важно чтобы для совпадающих значений реквизита выборка по этому реквизиту шла с соблюдением порядка кодов/наименований - тогда включаем "отбор"