Нужно было подсчитать количество проводок, сделанных определённым человеком (давайте сейчас опять не будем углубляться в то, зачем мне было нужно это).
Сначала было так:

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


Решил попробовать переписать через физическую таблицу. Как-то так:

ВЫБРАТЬ
   то же самое
ИЗ
   РегистрБухгалтерии.Хозрасчетный КАК Хозрасчетный
ГДЕ
   Хозрасчетный.Регистратор = &Ответственный
   И Хозрасчетный.Дата между &НП и &КП


Последний запрос работает в разы дольше (в 10 раз минимум).
Почему так происходит? Нет индекса на дате? Сомневаюсь...

(11) ЖКК кстати читтть надо))) "Где" отбирает по уже всем отобранным записям а виртуальные сразу отбирают с отбором) Понятно?)

(10) Это частый вопрос на собеседованиях, да) Вопрос де факто на понимание запросов)

(12)  все ослепли от блеска ;)

(12) Желудочно-кишечные кровотечения?
https://www.google.ru/search?q=жкк&aq=f&oq=жкк&aqs=chrome.0.57j0l3j61l2.590j0&sourceid=chrome&ie=UTF-8

В любом случае жесть. Грустно за 1С. На измерения можно было и  индекс повесить.
А за объяснение Спасибо!

(14) сочувствую)))

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

(16) Ну всяко бывает. Хотя если спросят сколько будет 2+2, то у 1С это не всегда очевидно)))

(15) При чем здесь индекс,если отбираются вначале все записи и потом только отбор применяется?

(17) ?

Профайлер что говорит?

(19) он молчит))

(18) 2+2=3,999999999999999999999999

(21) Это не только в 1с!)

(18) что значит все записи ?  В первом запросе отбор только на период установлен, преиодичность регистратор колбасит таблицу движений, то же самое наблюдаем о втором запросе, почему он работает дольше - не очень понятно.

(23) Из разных таблиц берутся данные все таки.

(24) брались бы из разных - не возникло бы вопроса

(25) вопрос от незнания все таки

(22) Где ещё? А как по-твоему тогда индексы используются? Которые являются неотъемлемой частью всех бд?

(27) лекции читать не собираюсь) уж извини однако) ученье свет!))

(28) На лекцию и не претендую.
Так всё-таки где же ещё такое используется?

(29) Таки претендуешь. Почитать инфу о СУБД не предлагать?

(29) я бы уже начал смотреть как запросы транслируются в скл
И результат запросов одинаковый ?

+ И ты хочешь сказать, что время выборки документов за определенную дату будет рости с ростом этих документов? И когда документов станет порядка 5000, запрос будет выполняться больше минуты (как это происходит со вторым запросом. Проводок больше 5к за период было)

(0) Потому что регистры бухгалтерии в 1С 8.x хреново реализованы.

расти*

(32) Я как-то сдуру запустил выборку из РБ на 1 500 000 записей. 48 минут запрос исполнялся. Из виртуальной таблицы те же 1,5 млн. записей выбрались за минуту.

(32) 5к проводов - это ничто

Странно это все ;)

(36) Суть не в количестве проводок. За определённый период было 5к проводок. Первый запрос выполнялся моментально, второй  - около пяти минут.

(30) О чём вообще речь? Хочется поспорить о чём угодно?
Я не говорю, что знаю все токности работы индексов, но знаю примерно представляю как они работают и даже уверен, что напишу индекс к базе.

(28) Так что на счёт выборки из документов за определённый период? Там сначала тоже все записи выберутся?

(38) выборка из документов? о_О)))

(39) Что такое? Нужно получить все ПТУ за квартал, например. Время будет расти с количеством документов (условие то же: ГДЕ ПТУ.Дата между НП и КП)?

Может виртуальная таблица лучше использует индекс. Профайлер будешь смотреть?

(41) Судя по скорости работы с реальной таблицей - она вообще не использует индекс.

(40) так .период между или пту.дата между ?
(42) ну да и скулю не разрешает ;)

(43)  Период.  Про ПТУ -  это вопрос на засыпку к Пеппи)

(43) Ну... не запрещает, но активно мешает.

48 минут на выборку всего 1,5 млн. записей - не думаю, что даже при отсутствии индекса это адекватное время для выборки. Потому что те же регистры накопления при непопадании в индекс аналогичный объем записей выбирают 1 минуту максимум.

(44) реальная таблица обычно в 60 раз медленнее виртуальной. Очень легко ориентироваться, например в виртиально выполняется 10 секунд, значит в реальной 10 минут. То что у тебя всего в 10 раз разница, так это замечательно, значит регистр спроектирован великолепно.

(46) Так почему так?
Что будет в случае документов из (32)

(47) Попробуй во второй запрос условие по периоду воткнуть в "ГДЕ"

+(48) Конечно же в первый.

v8: Что из себя представляет виртуальная таблица остатков регистра накопления?

поставим вопрос прямо: чем отличается нативная таблица, от виртуальной с периодичностью запись с точки зрения оборотов

(47) в реальной таблице может быть 100 строчек, а в виртияльной одна свернутая.

Хозрасчетный.Дата
ДАТА??????????

Как ты сдал спеца по платформе?????

подозреваю, что ты сделал
Хозрасчетный.Регистратор.Дата между &НП и &КП

если профайлером посмотреть тогда
там вложенный запрос
select ... from (select .. from .. group by )
если условие задать в виртуальной таблице тогда отбор where будет во вложенном запросе, а если задать в ГДЕ то отбор будет во внешнем запросе

В первом случае строится запрос к таблице оборотов между счетами, во второй к полной таблице проводок. Естественно первый гараздо быстрее

(52) Так стоит режим ЗАПИСЬ. Что там можно свернуть?
(55) Воу-воу, петросян, полегче со знаками вопроса.
В начале ответил, что период - писал от руки. Суть не изменилась
(56) Вот это больше похоже на правду. А что там за вложенный запрос? В случае документов его, подозреваю, не будет.. Спасибо

(58) не томи общественность, запусти профилер или в консоли какой, которая умеет показывать результирующий запрос

запрос к виртуальной таблице построится на основании физической в данном случае. Но в 1ом варианте отбор по дате идет сразу, а во втором идет неявное соединение всех регистраторов, о чем и грил (7).

П.С. Фига ты описался (8)...

(54) на стенах тоже пишут))

(0) Что за дата во втором запросе? Почему не период?

(62) Писал сразу в тему. Речь про Период
(60) В обоих запросах "неявное соединение" присутсвует...

(63) ну вот ты представь себя на месте бедного сервера. Тебе дали 2 задачи: 1ая выбрать документы по дате, а потом к выбранной паре-другой документов сделать соединение; и сделать соединение для всех, а потом выбрать по дате? ты чо для себя ыберешь

Подозреваю, что если убрать из текста обоих запросов

ГДЕ
  ИмяТаблицы.Регистратор.Ответсвенный = &Ответственный

то второй запрос будет выполняться быстрее.

PS При чем тут индексы вообще не понял

(12) Указание параметров виртуальной таблицы тут вообще не при чем.

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

(66) Так в первом запросе присутсвует такое же соединение. Разве нет?

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

(68) да

(67) в первом а) выбираются доки по индекс (у физич. таблицы индекс в т.ч. по периоду б) строится соединение, причем левые данные по не подошедшим регистраторам откидываются сразу в) для маленькой таблицы выполняется условие
2) а)выбираются все записи б) строятся все соединения в) для всей портянки смотрим условие

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

(71) (70)не?

(72) Не. Первый запрос неправильно описываешь. Вот тебе строка из первого запроса(подзапрос):

"FROM _AccRg462 T2 WITH(NOLOCK)
WHERE T2._Active = P1 AND (T2._Period >= @P2 AND T2._Period <= @P3)"

Запросы-то и отличаются только соединением таблиц документов: в первом случае - с подзапросом, во втором - со всей таблицей.

(73) а что не правильно то? Вот и ты написал, сначала выбираются доки по дате, а потом уже к ним идет соединение. я тож самое писал

Так скуль-то, по идее, должен сам план нормальный построить для второго, и сначала выгрести по индексу записи, а потом джойнить таблицы документов.
По запросу вы не поймете как конкретно выполняется выборка, надо план выполнения смотреть.

Он вообще-то декларативный.
Я таки подозреваю криво транслируется обращение через точку к реквизитам регистратора.

(75) план - это использование/неиспользование индексов и каких

(75) а если в запросе написано вот так, то и получаем неоптимальный запрос

(77) последовательность наложения условий тоже план

(76) да и странно было бы, если бы сервер 1с начал достраивать за юзера запрос, не зная что ему нужно. строит тупо соединение или подзапрос и все дела

(79) хочешь сказать сиквел сам поменяет условия местами?

(79) Причем последовательность наложения решает сам скуль, от того как ты напишешь это в запросе роли не играет.
Автор может поэкспериментировать, разыменовать руками поле регистратор.

(80) Пусть (73) покажет во что выливается Хозрасчетнй.Регистратор.Отвественный.
Он его не достраивает, а трансоирует, плюс плна строит скуль-сервер.

(81) Да. В запросе ты не указваешь как выбирать, а указываешь что выбирать.

(74) Он не доки выбирает, а содержимое таблицы:) Пиши точнее.

(79) сомневаюсь, ибо чо тогда б раздавали рекомендации, чтобы условия и их порядок попадал в индекс, хотя нужно перечитать талмуды

(82)+ Вернее разыменовать поле Хозрасчетный.Регистратор.Ответственный.

(84) да, согласен))

(82) причем тут разыменовать регистратор? это делает сервер 1с. Конечный запрос то будет тот же

(88) Откуда такая уверенность?
(85) Может это актуально для файловой версии или других версий скуля, МС скулю глубоко все равно.

(75), (82) да и все таки, в данном случае сначало построится джоин, а потом к нему будет применяться отбор. А уж какое из 2ух условий первое будет, тут играет вторую роль, ибо сначала джоин. т.ч. все логично

(75) Движок 1С сам за тебя не может решить, он только транслирует. Поэтому "виртуальная" таблица регистров - подзапрос(или вьюха, если хотите), а "физическая" таблица регистров - "аналог" физической таблицы.

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

(89) 1ый пункт: достраивать запрос - это функция сервера 1с. Для этого он делает еще запросы к таблице, где хранятся метаданные
2ой пункт спорить не буду. Нужно перечитать

(91) Я не говорю про движок 1С, я имею ввиду план запроса который построит скуль-вервер.

(79) Наиболее эффективная выборка будет происходить, если поля условий будут входить в индекс... Там ещё "покрытие" индекса будет иметь значение... Но ладно, это уж другие материи.

(92) Ну со сложными подзапросами, там просто иногда скулю башку сносит, и он неоптимально строит. Поэтому и рекомендуют временные  таблицы юзать. Иногда бывает запрос один и тот же, но от входных параметров меняется план и в даун уходит.

(94) Не прав. Оптимизатор совсем от запроса отойти не может. Он тебе оптимизирует описанный запрос, но по двум запросам одинаковый оптимальный план не построит:) И первый запрос по структуре оптимален. Второй неоптимален.

(97) Тут согласен.
Более того, как писал в (96) и для одного и того же запроса может построить разный план, в зависимости от входных параметров. Сталкивался с этим, правда на семерке в прямых запосах.

(98) Определение параметров запроса(для SQL-ля), при возможности, должно идти через вторичные таблицы. Недавно исследовали этот вопрос(правда, не для 1с),  сами сильно удивлялись оптимизатору. Т.е. не ссылка в параметре, а выборка ссылки из таблицы в параметре. Бред, но планы запросов становятся лучше.

(97) А не мог бы показать из профайлера кусок для второго запроса для

Хозрасчетный.Регистратор.Отвественный = &Ответственный

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

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

(100) Там что в первом случае, что во втором - херова туча джоинов:
"...
LEFT OUTER JOIN _Document161 T2 WITH(NOLOCK)
ON T1._RecorderTRef = P1 AND T1._RecorderRRef = T2._IDRRef
LEFT OUTER JOIN _Document217 T3 WITH(NOLOCK)
ON T1._RecorderTRef = @P2 AND T1._RecorderRRef = T3._IDRRef
LEFT OUTER JOIN _Document206 T4 WITH(NOLOCK)
ON T1._RecorderTRef = @P3 AND T1._RecorderRRef = T4._IDRRef
LEFT OUTER JOIN _Document207 T5 WITH(NOLOCK)
ON T1._RecorderTRef = @P4 AND T1._RecorderRRef = T5._IDRRef
LEFT OUTER JOIN _Document168 T6 WITH(NOLOCK)
ON T1._RecorderTRef = @P5 AND T1._RecorderRRef = T6._IDRRef
LEFT OUTER JOIN _Document188 T7 WITH(NOLOCK)
ON T1._RecorderTRef = @P6 AND T1._RecorderRRef = T7._IDRRef
..."

Все не уйметесь? (0) Предлагаю запрос к реальной таблице с условиями на период засунуть во вложенный запрос, а условие с ответственным применить уже к результату вложенного запроса. Замерить производительность и сделать выводы.

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

(100) Стандартный способ - разбиение на временные таблицы и их индексация.+ есть ещё способ - написание своих индексов для таблиц 1с.

(103) Я тешу себя надеждой что хотя бы так он поймет, когда система использует Clustured Index Search, а когда Clustured Index Scan, в какой момент неявные соединения становятся явными, и как на их длительность влияет количество строк исходных данных...

(105) Что за Clustured Index Search? Clustured Index Seek?

(101) Понятно. А само условие как проверяется ?

(107) Условие на что?

Хозрасчетный.Регистратор.Отвественный = &Ответственный

в (101) только сами соединения.

(109) "...LEFT OUTER JOIN _Document161 T3 WITH(NOLOCK)
ON T1.RecorderTRef = @P5 AND T1.RecorderRRef = T3._IDRRef..."

"...WHERE (CASE WHEN T1.RecorderTRef = 0x000000A1 THEN T3._Fld3713RRef..."

"...N'@P1 varbinary(1),@P2 datetime,@P3 datetime,@P4 numeric(1,0),@P5 varbinary(4)..."

" 0, 0x000000A1, 0x000000D9, 0x000000CE, 0x000000CF, 0x000000A"

(110) Спасибо.