Первый раз запрос вполняется раз в 100 дольше. Кеш отключил

от чего избавиться?

Кеш отключил.

Как?

а кэш отключил чтобы и остальные разы тоже медленно выполнялись, да ?

(0) Никак. Первый раз строиться план запроса и компилируется сам запрос. В хранимки его затолкай.

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

Кто где учился) http://v8.1c.ru/overview/Term_000000564.htm

(2) SET @@global.query_cache_size=0;
SET @@global.query_cache_type=OFF;

(5) Из какой профессии? Я для себя всё делаю

(3)Да. Для дебага нужно

+(6) Темой не попал)

(7) и как убеждаешьс что он отключился?

(5) суров.

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

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

2(10) по его предположению в память (для последующих разов) данные не попадают так как он отключил кэш

(0) Если первый запрос строится долго, а второй быстро...
То вас кривые запросы, и ошибочное представление об отладке.
Ибо во второй раз скуль данные уже выгребает почти в кэшированном виде :)

(12) Какой кэш... он поди понятие не имеет как работает скуль :)

(10) Я бы в первую очередь посмотрел на сам запрос, ибо есть методы написания, которые будут и при втором разе выполнятся долго :)

2(14) откуда такая уничижительная предпосылка? например в (7) он показывает как отключал. Но не показывает как проверял что он действительно отключился.
2(13) что значит "почти" и опять же, он утверждает что отключил кэш

(10) Вау, молодец..

2(10) с чего вы взяли что ему нужно чтобы запрос выполнялся быстро? Ему нужно чтобы первый и последующий разы он выполнялся одинаковое время. (зачем ему это нужно, и почему он просто первый раз не исключит из опытов - это отдельный разговор)

(18) Вам не кажется, что требовать от программы, что бы она работала с одной и той же скоростью, как это делает 1С, (т.е. медленно), это не от большого ума?

Больше склонен к тому, что у автора есть некая обработка, которая запускается не зависимо от времени выполнения запроса к SQL, т.е. автор не умеет отлавливать процесс завершения работы запроса. А от этого и его требование, что бы все было тупо медлен, но с "предсказуемой" периодичностью.
А вот тот факт, что запрос так же может выполнятся медленно в зависимости от самих данных, автор чего-то не упоминает.

...Или я просто сегодня груб?... (я не хотел)...

чтобы гарантированно убедиться, что кеш не влияет на скорость запроса, нужно после каждого выполнения оного запроса перезапускать комп с сервером скуля.
Хотя и то не факт...

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

(0) с mysql почти не работал, посмотри вот эту ссылку: http://www.stableit.ru/2010/02/querycache-mysql.html там есть пример - как посмотреть реальное значение query cache size.
В принципе, даже если кэш установлен в 0, может быть у тебя дисковая подсистема умная и сама какую-то часть данных кэширует.

(19) Вижу человека, не проводившего долгие часы-дни в отладке производительности запроса на нефайловой базе.

(0) Посмотри, нельзя ли запрос разбить на более мелкие подзапросы, поместить результаты во временные таблицы, проиндексировать.

(18) мне так показалось, т.к. это наиболее логично.
(20) мне кажется, достаточно будет сделать стоп-старт службе скл сервера.

(20)(25) для MS SQL Server гораздо проще и быстрее выполнить DBCC DROPCLEANBUFFERS.

2(25) Если читать предыдущие ветки автора, можно понять что а) не логично.
б) вообще не имеет отношения к 1Совской базе
2(22) Если это не МС СКЛ, но в Вин-среде, то безусловно файловая система умная, и помещает первый раз считанные файлы в системный кэш, это только МС СКЛ в Вин-среде читает низкоуровнево, мимо системного кэша, в свой собственный.

(25) нет.
(26) нет.

Есть ещё кеши контроллера диска.

(27) у меня нет столько времени, чтобы читать все ветки автора. Да и желания нет.
"Правильно поставленное техническое задание является половиной решения" (с)

хм...ТС.. Мехмат МГУ...
Грустно.

2(29) понятно, читать времени нет, безосновательно фантазировать на тему что же имел автор - есть.

(31) госпадя..
да автору уже и дела нет до этой темы, а вы тут все бубубу.

(32) Почему бы и не поворчать?

(0) мможет так?
declare @p1 int
set @p1=null
exec sp_prepare @p1 OUTPUT, NULL, N'SELECT *
FROM table1
'
exec sp_execute @p1
exec sp_execute @p1
exec sp_execute @p1

(30) Что именно тут грустного?
Винда может так данные кешировать?

2(35) не может, а точно это делает, читай (27)

(26) так жестче))
alter system flush shared_pool
alter system flush buffer_cache