Возник вопрос. Делаем запрос по срезу последних из большого регистра сведений с отбором по отделам. В зависимости от количества записей по отделу, запрос выполняется от 15сек до 15мин. Причем последующие запросы выполняются значильно быстерее, как я понимаю из-за кэширования SQL сервером. Можно ли как-то управлять этим кэшированием?

не правильно понимаешь

Кэшировать может и сервер предприятия

(0) что-то мешает посмотреть на сиквеле план запроса ?

(0) Управлять можно. Но не нужно. Оптимизатор сиквела сделает это гораздо лучше тебя.

Почему хочу управлять.

Делаю запрос с отбором Отдей1 (мало записей), выполняется 7сек.

Делаю запрос с отбором Отдей2 (много записей), выполняется 15мин.

Делаю запрос по Отдел2 после запроса по Отдел1 - 30сек.
Хочется чтобы запрос по Отделу2 выполнялся быстро.

делай запрос  по отделу1 и отделу 2

(5) так и хочу, но както не красиво

А переиндексация, обновление статистики и т.д. на сервере SQL выполняются?

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

(4) Проверь (7) и попадание в индексы. Параметры кеширования сервера нельзя трогать если у тебя запрос плохо работает. Трогай запрос.

(0)Точно ли там простой запрос выборка или есть соединения, условия и сложные поля?

Про (7) скорее всего делается.
(10) Простая выборка.

Отбор в параметрах виртуальной таблицы или в условиях?

(12) в параметрах

В МС СКЛ как управлять не знаю. В ДБ2 знаю.

(0) я бы сначала проверил, моделируется ли ваша ситуация на тестовой бд без других сторонних нагрузок.
Далее если не моделируется, то вариантов много:-)  скорее всего статистика на скл устаревает. А если моделируется, то понять - проблемы на сервере приложения 1с или скл сервере. Проверить и подтвердить, что проблемы на скл и связанные с кешем легко - из профайлера скл достаете два запроса и выполняете из менеджмент студии, параллельно запустив счётчик page life expentency. Если замедление будет и счётчик будет опускаться к 0 - то проблема действительно в кеше .  Кстати кешем мс скл управлять нельзя - только наблюдать:-)

(11) Это как "Скорее всего"? Проверьте.

Есть ли индекс по измерению Отдел?

Проверил, срез последних на регистре сведений из 5 000 000 записей делается <1.5 сек, с отбором по индексированному измерению.

(0) первый раз слышу про запрос на 15 минут.. может у вас там что нибудь неисправно? )

если в РС нет индекса по отделу, то скорее всего делается тэйбл скан, соответственно оно все и кэшируется. ну или скуль такой умный, что соображает - сейчас сделали запрос по этой таблице, надо бы ее кэшировать, поскольку что-то часто ее вызывают...

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

(0) Начать с плана запроса.

Жесткий проверить уже было? У вас диск рушится, а вы индексы перестраиваете...

2(20) он не умный, он просто ее кэширует после первого чтения. Размещает страницы в памямити и запоминает когда разместил. Если будет обращение к другим таблицам а памяти будет не хватать, он эти страницы постепенно заменит другими. Но если не будет, то так и будет держать их в памяти.