Различные планы выполнения для одной и той же хранимой процедуры

Question

У нас есть запрос, который занимает около 5 секунд на нашей производственной системе, но на нашей зеркальной системе (как можно более идентичной для производства) и dev-системах требуется менее 1 секунды.

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

Мы знаем, как исправить это, переустановив соединения и добавив подсказки. Однако на данный момент было бы проще, если бы нам не пришлось вносить какие-либо изменения в SProc (Paperwork). Мы также попробовали sp_recompile.

В чем может быть разница между двумя планами запроса?

система: SQL 2005 SP2 Enterprise на Win2k3 Enterprise

Update: Спасибо за ваши ответы, то получается, что это статистика. См. Сводку ниже.

Answer 1

Ваша статистика, скорее всего, устарела. Если ваши данные совпадают, пересчитайте статистику на обоих серверах и перекомпилируйте. Затем вы должны увидеть идентичные планы запросов.

Кроме того, проверьте, что ваши индексы идентичны.

Answer 2

- это данные размером & между вашим зеркалом и производством как можно ближе к нему? Если вы знаете, почему один запрос занимает больше времени, чем другой? можете ли вы опубликовать несколько подробностей?

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

Answer 3

Скорее всего статистика.

Некоторые мысли: Выполняете ли вы обслуживание на своих незапроданных системах? (например, индексы rebuidl, которые будут перестраивать статистику)

Если да, то используете ли вы одинаковые коэффициенты заполнения и статистики?

Вы регулярно восстанавливаете базу данных на тест, так что это 100%, как производство?

Answer 4

Если в вашей программе отсутствует опция WITH RECOMPILE, план выполнения будет кэширован после первого выполнения.

Вот простой пример того, как вы можете получить неправильный план запроса закэшированный:

create proc spTest 
    @id int 
as 
select * from sysobjects where @id is null or id = id 

go 

exec spTest null 
-- As expected its a clustered index scan 

go 

exec spTest 1 
-- OH no its a clustered index scan 

попробуйте запустить Sql в QA на производственный сервере за пределами хранимой процедуры, чтобы определить, если у вас есть проблемы с ваша статистика устарела или таинственные индексы отсутствуют на производстве.

Answer 5

Привязываясь к первому ответу, проблема может быть связана с функцией SQL Snaping Parameter Sniffing. Он использует первое значение, которое вызвало компиляцию, чтобы помочь создать план выполнения. Обычно это хорошо, но если значение не является нормальным (или каким-то странным), оно может способствовать плохим планам.Это также объясняет разницу между производством и тестированием.

Отключение параметра sniffing потребует модификации SProc, который, как я понимаю, нежелателен. Однако, после использования sp_recompile, передайте параметры, которые вы считаете «нормальными», и должны перекомпилировать на основе этих новых параметров.

Я думаю, что поведение параметра нюхание отличается от 2005 до 2008 года, поэтому это может не сработать.

Answer 6

Решение заключалось в пересчете статистики. Я упустил из виду, что, как обычно, у нас есть запланированные задачи, чтобы все это сделать, но почему-то администраторы не помещали один сервер, Doh.

Суммируя все сообщения:

• Проверьте установка те же
  • Индексы
  • Таблица типоразмеры
  • Восстановление базы данных
• План выполнения Кэширование
  • Если запрос выполняется та же вне SProc, это не план выполнения
  • sp_recompile, если он отличается
  • Параметр нюхать
• пересчитывать Статистика