Есть такой регистр сведений: 3 измерения, один ресурс, два измерения ведущие, на третьем стоит "индексировать".
Это регистр самый часто используемый (100+ пользователей), и периодически запрос к нему формируется крайней медленно, сейчас замерял под одним пользователем 65 вызовов запроса - 46 секунд.
Подскажите, можно ли его как то оптимизировать, в чем может быть проблема?
Вот текст запроса:
        Запрос = Новый Запрос("ВЫБРАТЬ
                                  |    УстановленныеПараметрыСрезПоследних.Значение КАК Значение
                                  |ИЗ
                                  |    РегистрСведений.УстановленныеПараметры.СрезПоследних(&Период, Измерение1= &Измерение1 И Измерение2= &Измерение2 И Измерение3= &Измерение3) КАК УстановленныеПараметрыСрезПоследних");
            Запрос.УстановитьПараметр("Период", Период);    
            Запрос.УстановитьПараметр("Измерение1", Измерение1);    
            Запрос.УстановитьПараметр("Измерение2", Измерение2);    
            Запрос.УстановитьПараметр("Измерение3", Измерение3);    
            
            Выборка = Запрос.Выполнить().Выбрать();
            Если Выборка.Следующий() Тогда
                Значение = Выборка.Значение;
            КонецЕсли;

А зачем один запрос выполнять 65 раз? Сразу никак?
А так - лови профайлером скуля и смотри, где в индексы не попадаешь

Нужно убрать СрезПоследних
Все условия загнать в ГДЕ
УПОРЯДОЧИТЬ ПО Период УБЫВ
Добавить ПЕРВЫЕ 1

(1) А что значит в индексы не попадаешь? у меня все три измерения поидее проиндексированы.
(2) Раньше так и было, потом поменял на срезпоследних, вроде быстро стало, по крайней мере у меня.
Причем, сейчас сделал в расширении как вы написали, стало быстро у меня, остальные не перезаходили, еще не понятно.
Очень плавающая проблема.

(3) Идеи - вещь хорошая, тут даже "Фауст" отдыхает. Но в них ещё попасть надо.

(3) А есть общий индекс по 3 измерениям?

(5) А как его может не быть для измерений регистра сведений?

Если регистр так интенсивно теребонькается, то возможно следует пересмотреть методологию решения.
Например, если часто делается запрос к срезу последних без указания периода, то включить в регистре использование итогов.
Если часто делается несколько запросов подряд с одними и теми же параметрами, то вызывать запрос из модуля с параметром "Повторное использование возвращаемых значений" На время вызова или На время сеанса.
Использовать вместо комбинации измерений одно измерение в виде нового слубежного справочника, который будет состоять из трёх реквизитов. По аналогии с КлючиАналитикиУчетаЗатрат или КлючиАналитикиУчетаНДС в бухне.
А может вы там вообще запросы в циклах фигачите.
Или в зависимости от контекста может имеет смысл получать некую выборку по Изм1+Изм2 и уже с полученными данными работать, выбирая по оставшемуся Изм3.

А вообще слишком мало информации.
Размер регистра, периодичность, типы значений измерений (простые/ссылочные/составные). Контекст работы с регистром.

(5) Не знаю, в режиме 1С есть настройка?

(7) Может быть из-за того, что одно измерение с типом План видов характеристик.

(7+) Размер данные 1.4 гб, индекс 2.9 гб, строк 4.8 млн

Если остатки получать не на дату просто срез (без параметра &Период), тогда включение итогов среза последних хорошо ускорит запрос.

(9) Да, вот мне тоже непонятно, план счетов есть таблица с предопределенными элементами, а пвх нет?

(9) Сам ПВХ по сути обычный ссылочный тип. А вот если тип характеристика - то там как правило "сильно"-составной тип, это уже может влиять.

может итоги стоит включить?

(14) как правило мне важен период, с точностью до секунды, даже текущий день

А может влиять порядок измерений? то есть допустим у меня заданы Изм1, Изм2, Изм3, а мне приходится часто выполнять запрос на Изм2,Изм3, по сути Изм1 в 90% случаях не нужно.

(16) Может. И даже таки да. Я же говорю - в индексы не попадаешь.

(16) Это сильно влияет, нужно создавать измерения в том порядке в котором наиболее часто обращаются к ним

(17,18) спасибо, буду пробовать!

(16) Порядок измерений у тебя должен быть Изм2,Изм3,Изм1.
если есть обращения и с отбором по Изм1 тогда если постаивить ему индексировать будет создать еще один индекс Изм1,Изм2,Изм3

А можно ли в 1с сделать индекс например изм3+изм1 и изм3+изм1+изм2?

(9) >> Может быть из-за того, что одно измерение с типом План видов характеристик.

Если ПлавВидовХарактеристикСсылка - то нет. Если Характеристика.ПлавВидовХарактеристик, то не исключено, что и может.

(21) Нет, https://its.1c.ru/db/metod8dev/content/1590/hdoc

(23) Спасибо большое.

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

(21) В базах данных, обычно, индексы по полям, а не по выражениям.

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

(27) Нет, не сумма. А вырезка из таблицы именно указанных полей. Которые используются не только для поиска, но и для получения самих данных, если все они лежат в индексе, без обращения к самой таблице. Из суммы трудновато получить слагаемые.

(27) "Или бывают еще произвольные выражения (типа alltrim)"
Бывают. Но далеко не у всех СУБД. MS SQL к таковым не относится.

(2) да, тоже рекомендую такой метод

Если что-то работало нормально, а потом перестало - скорее всего дело в статистике, не апдейтнута по конкретной таблице.

Да, если включены реальные итоги регистра сведений, то по ним например в версии 8.3.10 индексы вообще не работают. Не знаю, может после пофиксили

(0)
Есть 3 пути
1) Подражания - говори, что нужно попадать в индекс.
2) Опыта - переписывай запрос и замеряй быстродействие.
3) Размышления - открой этот чертов профайлер и смотри, почему sql читает так много данных

(0) Быстро и просто реализовать: отказаться от среза и переписать через ВременныеТаблицы.

Если регистр Нечасто меняется по периоду - тогда использовать "архитектуру Ненавижу 1С"

(31) Получается, я в своих ответах достиг идеала (в твоём понимании) ))))

(8) Конечно, нет.

(2) Какие аргументы не использовать штатное решение (включить итоги)?

(35) А что тебе даст включение итогов?

Автор пишет в (15): "как правило мне важен период, с точностью до секунды, даже текущий день".

То есть он использует срез последних с указанием конкретного периода.
А итоги регистра сведений содержат только текущие (распоследние) итоги. Для получения среза за конкретный период таблицы итогов использоваться не будут. Включать итоги имеет смысл только, если используется частое обращение к срезу без указания параметра &Период.

(35) У него слишком много отборов.

(0) То что (5) имел ввиду - скорее всего. В типовых сделали один справочник с тремя реквизитами по твоим измерениям. РС сделали одно измерение и один ресурс в твоем случае. Перед записью находят элемент справочника с необходимым набором измерений и если его нет, то создают. Далее запись в РС. Запись чуть медленнее, а чтение гораздо быстрее.

(18) "Это сильно влияет, нужно создавать измерения в том порядке в котором наиболее часто обращаются к ним" - скорее в обратном. Первым должно быть измерение, отбор по которому будет максимально обрезать количество записей по сравнению со следующими отборами. Т.е. РС который например хранить данные цен в разрезе магазинов номенклатуры и организации должен быть следующего вида: Изм1 = Номенклатура, Изм2= магазин, Изм3 = организация, ресурс цена. И ни как не должен быть таким: Изм1= Организация, Изм2=Магазин, Изм3=Номенклатура, ресурс цена.

В случае с 1С и этого иногда не достаточно, так как 1С очень плохо работает с запросами. Приходится извращаться и заводить один огромный служебный справочник, который будет содержать почти все вариации сочетаний: номенклатура, магазин, организация. Т.е. вместо индекса по трем полям ссылочного типа, заменяется индексом по одному полю ссылочного типа.

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

(40) " зачем привязывать структуру индексов к порядку метаданных" это вы что то сами себе надумали и напутали

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

А поскольку программист оставил в интерфейсе нам на все регистры накопления один универсальный отчет...

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

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

Но конечно, фирма 1с это не международная красная книга и заботиться о создании удобств для вымирающих видов не станет...

(0) Единственный нормальный способ - заменить 65 вызовов на один. Пускай ты получишь лишние данные, но ты их выгрузишь в ТЗ, и следующие 64 будешь отрабатывать мгновенно поиском по ТЗ. Конечно, если эти 65 вызовов хоть чем-то объединены логически.

(43) Хорош ныть, в отчетах порядок группировок сохраняется. И в универсальном тоже.

(40) Я такую фичу с платформы 8.2 все жду, уверен что когда то дождусь.

(48) угу. Мне тоже сначала показалось, что на фокспро одной двухчасовой лекции про индексы недостаточно, чтобы качать права по поводу того какую ...ню сделали в 7.7....

+(50) зато теперь понятно, почему... Sql так не может!

(49) А дождался пока, наверное, только ссылку в (23) - как и в каком случае индексы строятся.

(35) До версии 8.3.13 в таблицах итогов тупо не было индексов. Забыли добавить )

(40) +тыща. Очень надо возможность строить индексы по произвольному набору полей.

(54) Иди в фузину. Там можно

(54) можно что?

(0) "периодически запрос к нему формируется крайней медленно" - блокировки если остальное не тормозит. Что это за регистр, что его нужно так "теребонькать", да ещё и куча пользователей одновременно?
Кто в это регистр и что пишет, в каком объеме и как часто?