Сейчас делаю так:
CHECKPOINT;
GO
DBCC DROPCLEANBUFFERS;
GO

Не слишком ли это? Вы как делаете?

а зачем?

(1) Для отладки запросов. Тупо проверить 2 варианта. Который легче.

перезапускай службу

(3) Скуль?

(0) DBCC FREEPROCCACHE - это для всех баз,

1. select name, database_id from sys.databases
// получаем идентификатор нужной БД.

2. DBCC FLUSHPROCINDB(<database_id>)
// очищаем кэш по id БД.
это для определённой базы

(5) FREEPROCCACHE - это кэш планов запросов, а не кэш данных

(6) Прав, невнимательно прочёл. Это когда статистику обновляем чистим кэш плана запросов.

то что тс прописал - кэш данных чистит. но кэш процедур тоже бы неплохо

(0) Это помогает когда пользователь с одного компа на другой прыгнул на время отпуска например сотрудника, а у него 1С принтер по умолчанию запоминает старый?

(9) Нет. Это из другой повести.
Почему я задал такой вопрос.
потому как оптимизирую запрос. Но Получается как - если запустить (0) то 2 варианта запроса, старый и новый, работают, по времени, примерно одинаково. Но в продуктивной базе второй запрос работает быстрее раза в 2.
Я понимаю, что некоторые данные практически всегда в кеше скуля. Но вот как правильнее найти самый продуктивный вариант.
Тестируя 2 варианта в рабочей базе первым запросом мы подтянем некешированные данные, а второй будет уже , с учетом кеша быстрее работать.

Нет ли случаем такого, что бы можно было, кеш откатить на минут 10 назад?

Или другой вариант.
Можно как то указать скулю не кешировать данные временно.
По сути из консоли запросов, перед запросом отключать кеширование, а после включать снова.

(10), (11) А зачем? Тебя ведь не теория а практика интересует.

А что планы запросов говорят?

(10) Если ты думаешь что проблема в кэше, включи статистику чтений и выполни запрос в SSMS, посмотри сколько там было физических.

Можно просто посмотреть счетчик buffer cache hit ratio, если он норм, то и проблема не в этом.

Но проблема 100% не там где ты ее ищешь. Выложи актуальные планы в формате sqlplan, только так можно точно сказать в чем разница.

(12) Планы не смотрел. Там запрос многоэтажный.
Ну вот что бы в реальной базе испытать 2 варианта, без влияния кеша.

(10) (14) какой-то неправильный подход.
Что мешает запустить запрос1, потом запрос2, потом запрос1, потом запрос2 - несколько раз. Записываешь показания каждого.
В результате будет видно работу обоих запросов на прогретом кэше.
На непрогретом особо смысла не вижу - ведь в продуктиве запрос будет работать на прогретом.
А если запрос стартует на холодном раз в (неделю?) - зачем его оптимизировать?

У тебя консоль запросов какая? Самая простая? Или хотя-бы время каждого пакета можно увидеть?

(16) Мне как раз нужен вариант на прогретом кеше,  но не горячем, а твой вариант покажет на горячем. В нем все данные в памяти.

(17) Тут только планы актуальные разгребать + смотреть в контексте работы пользователей. А то выяснится, что к моменту твоих тестов, кто-то такой же отчёт уже собрал руками подручными средствами.