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

при выполнении на локальном компе замер производительности показывает очень маленький процент, от общего времени проведения, а при проверке на компе который работает по сети, показывает что выполнение запроса занимает 50% всего времени. Можно ли его как то оптимизировать?
По полям "Доктор", "ВремяНачала" и "время окончания" проставлено индексирование.

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

Видимо из за того что много условий запрос тормозит?

Если этот запрос сделать пакетами, то есть сначала наложить фильтр по дате а потом его ковырять на предмет совпадения времени и врача, даст ли это прирост скорости?

Запросы нужно оптимизировать с использованием sql profiler. Смотреть нужно на показатели duration,reads. Чем меньше будет duration и reads, тем лучше ты оптимизировал запрос.

Дык был бы там еще SQL...

(0) помести все приемы проведенные приемы за день в ВТ, а уже потом наложи на ВТ условие по времени. а еще лучше сделать регистр сведений под это дело

(4) Глупости. Ну посмотрит он на duration и reads, а дальше.

Надо смотреть, где возникают indexscan, большие промежуточные выборки и "распараллеливание ветвей алгоритма" с дублирующим чтением (и такое бывает).

(7) Не глупости. Понятно что нужно смотреть план запроса. Исключать tablescan и добиваться indexseek. Но после оптимизации количество чтений и время выполнения запроса сразу уменьшается.

(8) Если статистику обновить.

"НАЧАЛОПЕРИОДА(Прием.Дата, ДЕНЬ) = &ДатаП"
Я бы переделал на
Прием.Дата МЕЖДУ НАЧАЛОПЕРИОДА...

"Доктор", "ВремяНачала" и "время окончания"
У тебя Дата и так с индексом  - больше и не надо

(7) Как бы надо смотреть план запроса целиком и особенно на самые длительные операции. Например сам по себе индекс скан может быть и добром

(0) Общие рекомендации:

1. ИЛИ переделелать на объединение двух запросов
2. Заменить НАЧАЛОПЕРИОДА(Прием.Дата, ДЕНЬ) = &ДатаП на Между

(13) + Вопрос еще по индексу по реквизиту "Доктор", но в эту сторону надо смотреть с оглядкой, на возникающие здержки при записи документа.

наверняка в плане у тебя индекс скан или индекс seek where

С SQL встречаюсь нечасто.
sql profiler это что? Какая то утилита на SQL server?

сделай индексными реквизиты
ВремяНачала
ВремяОкончания
Доктор

а вообще, надо юзать не документ. а регистр сведений :)

(16) они уже индексные,
насчет регистра сведений подумаю, идея неплохая.

Спасибо

поможет тупо замена НАЧАЛОПЕРИОДА(Прием.Дата, ДЕНЬ) = &ДатаП на
Прием.Дата МЕЖДУ &ДатаП И КОНЕЦПЕРИОДА(&ДатаП, ДЕНЬ)

остальное даст крохи уже

а вообще - в идеале надо чтобы документ писал, ну допустим, в регистр накопления на начало приема приход 1 и на конец приема расход 1. тогда количество обслуженных в период считается через Рег.КоличествоРасход.
и контролировать пересечение проще

а для особо упоротых^w упорных на регистре расчета можно.

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

(16) ПРосто так делать что то индексным не надо... )

(17) А в чем разница между регистром сведений и документом? Суть то не изменится ))

(19) ИЛИ может дать неплохой прирост

(21) Регистр расчета это сплошной тормоз.

(24) просто так не надо, а для выборок и связей по этому реквизиту - надо.

(24) ну про разницу между РС и документом думаю это вопрос реторический?;)

(27) что значит для выборок и связей, это и есть просто так.

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

(28) Конечно нет.... данные они и в Африке данные....

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

(31) Надо оценивать, без анализа плана запроса сложно.

(32) + Время начала и Время окончания явно не Период ))) так что смысл есть.... но опять без сбора симптомов и статистических данных мы гадаем на кофейной гуще.

(29) >что значит для выборок и связей, это и есть просто так.
молчу молчу )))))))))))))))

(34) Вот вот, ради конкретной выборки и/или связи индексы не вешают...

кстати, я в (31) наврал :) почему-то был уверен, что кластерный по периоду, а он, оказывается, по ссылке. Ну тогда может и по другому будет, но поскольку 1с не умеет делать нормальные индексы на несколько реквизитов, скорее всего оптимально будет сделать индекс на доктора,, но в таком случае на ИЛИ опять пофигу

(35) перечитай условие в (0) :) и можешь мне про индексы ничего не говорить)))

(37) И что в условии (0) такого?

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

(37) Вы явно не вкурсе как строится план запроса. Индексирование может не помочь вообще, как у Автора, так как у него если почитаешь ветку индексы стоят и на доктора и на даты.

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

(38) "который работает по сети" :-)

(41)+ подчиненного регистратору периодического регистра, в случае РС

(41) регистр периодический?;)

(42) Между прочем это важное замечание, не исключено что у автора файловая ))

(45) ТОгда все наши потуги идут лесом ))))

(40) когда я захочу оценить уровень моих знаний - я обязательно обращусь к вам, ладно?:)

(47) Принимаю по предварительной записи, очередь стоит.

(48) ну год на 2040 можете смело делать запись)))