Один и тот же запрос, разные планы выполнения - PullRequest
8 голосов
/ 25 мая 2010

Я пытаюсь найти решение проблемы, которая сводит меня с ума ...

У меня есть запрос, который очень быстро выполняется на сервере QA, но он очень медленный в работе. Я понял, что у них разные планы выполнения ... поэтому я попытался перекомпилировать, очистить кэш для планов выполнения, обновить статистику, проверить тип сортировки ... но я все еще не могу найти, что происходит ...

Базы данных, в которых выполняется запрос, точно такие же, а серверы SQL также имеют такую ​​же конфигурацию.

Любые новые идеи будут высоко оценены.

Спасибо, A.


Я только что понял, что на сервере QA запущен SP3, а в работе SP2. Может ли это оказать какое-либо влияние на этот вопрос?

Ответы [ 5 ]

2 голосов
/ 25 мая 2010

Я думаю, это может быть связано с объемом имеющихся данных. Это случилось с нами один раз, когда запрос буквально летел на сервере QA, но был невероятно медленным в производстве. После недолгой разборки мы обнаружили, что на QA-сервере было 15 тыс. Строк, а на производстве 1,5 млн.

НТН

2 голосов
/ 25 мая 2010

Возможно ли, что рабочий сервер имеет больший размер базы данных? План может отличаться, поскольку он основан на статистике содержащихся в нем данных.

1 голос
/ 25 мая 2010

Если план выполнения был таким же, а один медленным, это была бы загрузка базы данных, аппаратное обеспечение, блокировка / блокировка и т. Д.

Однако, если планы выполнения отличаются, что-то отличается между двумя базами данных. Являются ли статистические данные актуальными в обоих случаях, имеют ли они одинаковые схемы, одинаковые индексы, одинаковое количество строк, одинаковое распределение значений PK и индекса и т. Д. Откуда поступили данные QA, случайные данные или это восстановление из производства?

0 голосов
/ 16 мая 2012

Я столкнулся с этим недавно, и вот что я нашел.

У меня было две базы данных, которые по сути были копиями друг друга. В одной версии TVF запускалась 1 секунда, а в другой - 15 минут.

Планы выполнения базового кода SQL были очень разными. Я смог исправить это, восстановив некоторые индексы, на которые опирался TVF. Планы выполнения не совпадают, но это сильно изменилось. И время выполнения уменьшилось примерно до секунды.

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

Итак, подведем итоги: убедитесь, что вы смотрите на фрагментацию ваших индексов, даже если они имеют одинаковую структуру или схожие скорости фрагментации.

0 голосов
/ 25 мая 2010

Отключить параллельное выполнение запроса на производстве:)

...