Доброго вечера. Помогите разрешить мои сомнения и вопросы... следующая ситуация: есть независимый регистр сведений, в него пишутся события по времени, каждый день около 2000. На форме обработки есть динамический список куда запросом вытягиваются эти события ограниченные условием в запросе...например "с начала текущего дня", так как они туду добавляются, то запрос часто перевыполняется. Подскажите при количестве записей около миллиона это же будет жутко тупить? и как можно данную процедуру оптимизировать....?База файловая. 1С 8.3. Заранее спасибо

Можно.
Заходим на форму. Ctrl-A, Del, Ctrl-S, F7
И начинаем думать сначала

Напили миллион записей и проверь.

Выбрать первые, и максимум по ключу. Это должно спасти отца русской демократии.
Ну в крайнем случае не максимум, а исключить ранее быбранные.

(3) сорри. Про дс проглядел.

(1) В какую сторону думать?) От совета не откажусь.

(2) проблемно...

(6) не думаю...

Может быть есть возможность осуществлять первоначальную выборку , например начиная со числа -1 день от текущей даты, и уже на основе ее данных формировать запросы?

(7) 600 000 записано :))

(8) В запрос динамического списка таблицу не передать, какой толк от первоначальной выборки? Никакого.

(7) прав. в чем сложность.
А по сути: дин. список читает данные порциями. Я не знаю, что ты написал в запросе. Но обычно дин. список на уровне sql преобразуется в: select top 50 (если кто знает точный  размер порции для ДС в 8.3, пусть напишит) from "НазваниеТаблицы" with (NOLock) where "Условие".
Отсюда вывод:
1. упрощать запрос
2. поиграть с индексами. Нужны индексы для полей "Условие". Индексы должны быть без "разрывов". Т.е есть условия по полю1, полю2, полю3. Индексы должны быть у всех полей, а не только поле1, поле3. И в условие не должно быть "НЕ", "ПОДОБНО" и пр.

(11) опередил)

(0) читай оптимизация запросов, индексы)

черт. У него файловая! А как 1с работает в этом случае? Я лично не знаю.

В общем, если в список выводится более 100000 записей начинаются жесткие тупняки )) Но если в списке порядка 2-5 000 записей, то никаких замедлений нет.  Запросы отрабатывают штатно.

(11) запрос на уровне выбрать события ИЗ регистрСведений ГДЕ Дата события МЕЖДУ ДатаНачали И ДатаКонца...

Ок. Будем считать что в 1с не идиоты. И для запросов они тоже используют индексы.
Выведи весь запрос.

(17)

    Запрос.Текст =
        "ВЫБРАТЬ
        |    Заказы.ИДЗаказа,
        |    Заказы.Время КАК Время,
        |    Заказы.Телефон,
        |    Заказы.Карта,
        |    Заказы.Льгота,
        |    Заказы.Ожидание
        |ИЗ
        |    РегистрСведений.Заказы КАК Заказы
        |ГДЕ
        |    Заказы.Время МЕЖДУ &НачСмены И &КонСмены
        |    И Заказы.Статус <> &Снят";

Анафейхоа в динсписок (да и вообще в список) выводить 100500 записей? Кто их читать будет?

Начальнике хочет чтобы диспетчер видел все события за день. (( Их не будет 100500 конечно же...тысяч 2 максимум) Но...за год в самом регистре наберется под лям(

Ну и файловый вариант смущает )

(20) "если в список выводится более 100000 записей начинаются жесткие тупняки"
"если в списке порядка 2-5 000 записей, то никаких замедлений нет"
Ты уж определись

Время  - проиндексирован?
Можешь Заказы.Статус <> &Снят поменять на Заказы.Статус = &НеСнят

(23) Могу. Это из-за НЕ РАВНО?

Статус тоже проиндексировать

(22) Это я к предложению потестировать на  миллионе записей в регистре. Так как создались они текущейдатой, то и в список вылезли сразу все ) ИРЛ такого надеюсь не будет )

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

Попробуй. Отпишись по результату.

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

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

Первое измерение индексируется автоматически по нему не обязательно ставить "индексировать".

Измерение только ИД, осьтальнок ресурсы

Тогда давай помедитируем вот над такой табличкой:
Индексы непереодического регистра сведений.

Измерение1 + [Измерение2 +...]    Есть хоть одно измерение регистра.
Индекс, включающий все измерения в том порядке, в котором они заданы при конфигурировании.
ИзмерениеN + Измерение1 + [Измерение2 +...]    Измерению "ИзмерениеN" задано свойство "Индексировать" или свойство "Ведущее" и при этом это не первое и не единственное измерение.
Индекс, включающий все измерения. Первое поле - ИзмерениеN, затем все остальные измерения в том порядке, в котором они заданы при конфигурировании.
Реквизит + Измерение1 + [Измерение2 +...]    Реквизиту "Реквизит" задано свойство "Индексировать".
Индекс в котором первое поле - Реквизит, затем все измерения в том порядке, в котором они заданы при конфигурировании.
Ресурс + Измерение1 + [Измерение2 +...]    Ресурсу "Ресурс" задано свойство "Индексировать".
Индекс в котором первое поле - Ресурс, затем все измерения в том порядке, в котором они заданы при конфигурировании.

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

Не правильно написал. Надо: Сможем провести поиск только по первому полю из индекса (ресурс+ иземерение1+...), при условии что у данного ресурса стоит параметр "индексировать".

Затем частичное сканирование.

(36) Оставил условие только по времени, время  индексируется. Отрабатывает значительно быстрее, при работе 3-х пользователей одновременно никаких нареканий нет. Можно конечно более детально замерить производительность запроса, но...пока нужды нет. Тес проводился на РС с 2 500 000 записей. В дневную выборку попадало 5 000.  Результат даже на файловой базе пристойный.  Я так понимаю, что все вышесказанное будет справедливо и при переезде на серовер SQL?

(37) Это как и раз было для SQL.