Ну и соотвественно хотелось бы это как-то ускорить.
Но в первую очередь  определить причины нынешней ситуации

Если пользоваться штатными возможностями, то использование для доступа к периодическим згначениям через
Пер = СоздатьОбъект("Периодический") - позволяет добиться ускорения примерно 25%

У нас на базе зачастую наблюдается торможение при обращении к курсу валюты.

Через профайлер видно, что выполняется такой запрос
exec sp_executesql N'Select * from _1SCONST(NOLOCK) where ID=@P1 and OBJID=@P2 and DATE<=@P3 order by ID DESC, OBJID DESC, DATE DESC, TIME DESC, DOCID DESC, N'@P1 int,@P2 varchar(9),@P3 datetime', 92, '     2   ', 'Dec  9 2009 12:00:00:000AM'
и генерирует READS - 69993 и DURATION - 593
что видно, что зашкаливает.

Посмотрев план запроса - можно увидеть, что он сканирует таблицу констант и вытаскивает оттуда порядка 2800 строк.
Реиндексация не помогала. Помогло обновление статистики. Сейчас у меня статистика обновляется каждый день, т.к. размер базы уже порядка 65 Gb. В справочнике _1sconst сейчас порядка 2 200 000 записей.

По поводу сортировки - ты не прав. 1С использует правильную конструкцию, т.к. только в этом случае идет точное попадание в индекс IDD
#----Indexes------
# Name                           |Descr         |Unique|Indexed fields                                              |Type      
I=PK__1SCONST                    |              |1     |ROW_ID                                                      |1         
I=IDD                            |              |1     |ID,OBJID,DATE,TIME,DOCID,ROW_ID                             |0         
I=DOC                            |              |1     |DOCID,ACTNO,ROW_ID                                          |0   


Я в базе переделал стандартную функцию получения курсов валют через параметрезированный запрос и  убрал в программе везде обращения напрямую типа Валюта.Курс.Получить() на глПолучитьКурс(Валюта,Дата). Это решило данную проблему и скорость существенно возросла.
У нас комплексная база и документ переоценка валют проводился порядка 40 мин. После вышеупомянутой замены стал проводится 5 мин.
Но таким образом нельзя решить проблему в Операциях, когда 1С каким-то своим способом обращается к константам для обновления текущего курса валюты в проводках.

При попадании в индекс сортировки просто не будет.

Что выберет sql еще зависит и от данных и от статистики
только что проверил

Select * from _1SCONST(NOLOCK)
where ID=92 and OBJID='     2   '
and DATE<='Oct  1 2009 12:00:00:000AM'
order by ID DESC, OBJID DESC, DATE DESC, TIME DESC, DOCID DESC


Select * from _1SCONST(NOLOCK)
where ID=92 and OBJID='     2   '
and DATE<='Oct  1 2009 12:00:00:000AM'
order by DATE DESC

Для обоих запросов sql выбрал cluster index scan ( строк в выборке 163 )

У меня собственно сделан такой запрос

Это при загрузке 1С
ТекстЗапроса="
     |DECLARE @пВалюта char(9), @пНаДату datetime
     |SET @пНаДату = ?
     |SET @пВалюта = ?
     |SELECT CASE WHEN Кратность=0 THEN Курс ELSE Курс/Кратность END Курс
     |FROM (
     |SELECT $ПоследнееЗначение.Валюты.Курс(@пВалюта,@пНаДату) Курс
     |       , COALESCE($ПоследнееЗначение.Валюты.Кратность(@пВалюта,@пНаДату),1) Кратность ) Курсы
     |";
     
     глЗапросПоВалютам=СоздатьОбъект("ODBCRecordSet");
     глЗапросПоВалютам.Подготовить(ТекстЗапроса);
     глЗапросПоВалютам.ДобПараметр(1,10,17,0);
     глЗапросПоВалютам.ДобПараметр(1,14,9,0);


Функция глКурсДляВалюты(Валюта,ДатаКурса) Экспорт
     
     Если ПустоеЗначение(ДатаКурса)=1 Тогда
           ДатаКурса=РабочаяДата();
     КонецЕсли;      
     
     Если ТипЗначенияСтр(ДатаКурса)="Документ" Тогда
           ДатаКурса=ДатаКурса.ДатаДок;
-- не вытаскивает курс на документ, т.к. у меня параметр типа дата
     КонецЕсли;      

     глЗапросПоВалютам.УстПараметр(1,ДатаКурса);
     
     Если Валюта=Рубли Тогда
           // Для базовой валюты курс всегда равен 1, поэтому отображаем курс Основной валюты
           глЗапросПоВалютам.УстПараметр(2,Константа.ОсновнаяВалюта);
     Иначе    // для других валют записываем их собственный курс
           глЗапросПоВалютам.УстПараметр(2,Валюта);
     КонецЕсли;
     
     Возврат глЗапросПоВалютам.ВыполнитьСкалярный();
     
КонецФункции

Ну если поставить TOP 1 понятно, что проблем бы не было. Только как ты это скажешь делать 1С?

Так ты определись, что ты хочешь - всю конфигурацию перелопатить на предмет нахождения таких конструкций и замену их на прямой запрос или ничего не трогая ускорить их выполнение.
Практика показывает, что лучше переделать где это можно. Я тебе написал пример в посте #13.

Никто не переходит на личности. Извини если что не так сказал.
Я просто обращаю внимание на то, что для начала нужно определить что в итоге хочешь достичь и какими средствами.
Твоя проблема была в медленном получении периодических реквизитах, а конкретно при выборке данных из таблицы _1sconst.
Здесь есть два решения:
1. Менее трудозатратный, но не всегда гарантирует результат
2. Трудозатратный, но с гарантированным результатом.

Остался один вопрос
Зачем в родном 1с запросе

exec sp_executesql N'Select * from _1SCONST(NOLOCK)
where ID=@P1 and OBJID=@P2 and DATE<=@P3
order by ID DESC, OBJID DESC, DATE DESC, TIME DESC, DOCID DESC'
, N'@P1 int,@P2 varchar(9),@P3 datetime', 92, '     2   ', 'Oct  1 2009 12:00:00:000AM'

сортировке используется ID DESC, OBJID DESC, в этом есть
какой-то смысл, это баг , может быть так надо было писать под sql 6.5 или что-то еще ?
Может этот вопрос вынести в отдельную тему ?

Z1 писал(а) 11. Декабря 2009 :: 06:38:


В данном случае сортировка по дате, только для того, чтобы вытащить последнее значение из всего кол-ва значений по дате и видимо ID и OBJID не влияют на индекс, т.к. он уже отфильтрован по ним.
В плане запросе такой запрос не формирует раздела SORT

Если поставить
order by c92_vv.ID, c92_vv.OBJID, c92_vv.date desc, c92_vv.time desc, c92_vv.docid desc, c92_vv.row_id desc
как в оригинале, то план запроса уже использует Cluster Index Scan.

elkpro писал(а) 11. Декабря 2009 :: 09:01:

В оригинале так:
order by c92_vv.ID desc, c92_vv.OBJID desc, c92_vv.date desc, c92_vv.time desc, c92_vv.docid desc, c92_vv.row_id desc

А теперь расскажи, как у тебя из select * получилось select cast(c92_vv.value... ?

Как всё плохо.. 

Если в таблице больше 1600 записей - обнови статистику with fullscan.

Z1 писал(а) 10. Декабря 2009 :: 06:58:

На самом деле, клиент 1С кеширует результат select *, и, при последующих обращениях к реквизиту, больше не посылает запросов на сервер. В отличие от предлагаемых тобой select top 1 *.

Z1 писал(а) 11. Декабря 2009 :: 08:57:

sp_executesql там - именно для того, чтобы "to reuse the execution plan it generates for the first execution".

Z1 писал(а) 12. Декабря 2009 :: 08:49:

В том, что при избирательности в 1.36% сканируется вся таблица, вместо поиска по индексу. Для таблицы размером в два с лишним мегабайта это уже играет роль. Не возьмусь ставить диагноз по фотографии, но что-то с твоим сервером не в порядке.

berezdetsky писал(а) 12. Декабря 2009 :: 17:39:

Еще раз переиндексировал и обновил статистику.
Может влияет на ситуацию еще и распределение дат
Всего разных дат Select DISTINCT DATE from _1SCONST = 1363


Если ограничить значение снизу
Select * from _1SCONST(NOLOCK)
where ID=92
and OBJID='     2   '
and DATE <= 'Oct  1 2009 12:00:00:000AM'
and DATE >= 'Jan  2007  12:00:00:000AM'
order by DATE DESC, TIME DESC, DOCID DESC
то запрос идет по IDD
При более ранних датах(снизу)  sql сервер выбирает кластерный индекс.