Выборка из независимого регистра сведений: оптимизация #749380

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

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

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

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

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

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

проблемно...

не думаю...

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

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

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

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

опередил)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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