https://www.dropbox.com/s/z66h6k3iinfdrtb/2018-11-13_07h12_19.png?dl=0

есть часто выполняемый запрос (поиск физ лица через ввод по строке в фоне) и каждое утро запрос этот выполняется порядка 4 секунд

полез я почитать умных статей про настройку SQL - и есть там совет выставить максимальную степень параллелизма для работы с 1С = 1
у нас на то время стояло 4
поставил - и о чудо - практически мгновенный поиск

но не долго длилось счастье
на следующее утро поиск опять стал выполнятся 4 и более секунды
меняю данный параметр назад на 4 - и ... "практически мгновенный поиск
"

сегодня до меня дошло - циферка в данном параметре не влияет на скорость поиска - главное поменять её

статистики?

(0) SQL 2005?
Сталкивались с таким, почти один в один. Переключение этого параметра примерно аналогично сбросу кэша планов
DBCC FREEPROCCACHE
А то, что это помогает, говорит о том, что статистики устаревают.

(1) а не будет ли там случайно замедлений на новой компиляции планов запросов?

(0) читал статьи по обслуживанию баз?

(2) Будет. а куда от этого деться?
А maxdop и статистики связаны слабо

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

(5) А зачем кэш нужно сбрасывать после обновления статистик?

(6) Ты не поверишь... Кеш при расчёте использует статистики для создания плана запроса...

(7) ой ли.., удивил..., а ответ на вопрос не увидел

Повторю вопрос: Зачем нужно очищать процедурный кэш?

(9) Тебе по слогам повторить?
В процедурном кеше лежит рассчитанный план запроса (предварительный). Если у тебя статистики изменились, то план будет неактуальным

(7) "то план будет неактуальным", так нахрена его очищать?
Про "вымывание кэша" слыхали?

(6) Я не еврей, но таки отвечу: а зачем пересчитывать статистики, если использовать старый кэш?

(12) на основании статистикаи строится план запроса, при обновлении статистики, как было сказано в (10) план запроса будет неактуальным, соответственно будет перестроен оптимизатором, а старый "вымыт", потому как неактуальный.

(13) Отсюда вопрос: Зачем очищать кэш планов запроса, если неактуальные планы помечаются и "вымываются"?

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

(15) вот и я про это..., зачем вообще это делать

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

Это был SQL 2005, база не шибко большая, порядка 50Г. При больших объёмах так махать шашкой конечно нельзя.

вот ребята тестили:
http://www.sql.ru/forum/1069066/nuzhno-li-vypolnyat-ochistku-procedurnogo-kesha-posle-obnovleniya-statistiki

Добавлю:
Обновление статистики гарантирует, что запросы будут компилироваться с актуальной статистикой. Однако обновление статистики вызывает перекомпиляцию запросов. Рекомендуется не обновлять статистику слишком часто, поскольку необходимо найти баланс между выигрышем в производительности за счет усовершенствованных планов запросов и потерей времени на перекомпиляцию запросов.
https://docs.microsoft.com/ru-ru/sql/relational-databases/statistics/update-statistics?view=sql-server-2016

Я так не игра. этот сиквель древний как говно мамонта зачем его вообще юзать!?

(20) заведите отдельную ветку. к теме ветки Ваш выперд не относится.

(0) извините. с грубил.

(20)  извините. с грубил.