Странно, но копирование параметров значительно ускоряет SP в SQL Server 2008

Question

Когда я запускал sproc с помощью SqlDataAdapter.fill (), я заметил, что это заняло более 90 секунд, когда запуск того же sproc в Management Studio занял всего 1-2 секунды. Я начал возиться с параметрами, чтобы попытаться найти проблему, и в конце концов сделал, хотя это странно. Я обнаружил, что если я просто объявил три новые переменные в sproc и напрямую скопировал в них содержимое параметров, а затем использовал эти новые переменные в теле sproc, метод fill () упал до 1-2 секунд, как запуск sproc непосредственно в студии управления. Другими словами, делая это:

CREATE PROCEDURE [dbo].[TestProc]
    @location nvarchar(100), @startTime datetime, @endTime datetime
AS

declare @location2 nvarchar(100), @endTime2 datetime, @startTime2 datetime
set @location2 = @location
set @startTime2 = @startTime
set @endTime2 = @endTime

--... query using @location2, @startTime2, @endTime2

Если я изменил хотя бы одну из ссылок в теле запроса с @ startTime2 обратно на @startTime (фактический параметр, переданный из C #), запрос снова переместился на 90 с или даже больше.

ТАК .... почему в мире SQLDataAdapter или SQL Server заботится о том, что я делаю с его параметрами после их передачи в sproc? Почему это повлияет на время выполнения? Любое руководство о том, как устранить эту проблему, будет высоко оценено. Спасибо!

Редактировать: Хотя я мог бы поклясться, что между выполнением запроса из C # с использованием SqlDataAdapter и использованием Management Studio есть разница, но на данный момент я не могу воспроизвести разницу. Теперь управляющей студии также требуется> 90 секунд для запуска sproc, когда я НЕ копирую параметры. Это огромное облегчение, потому что это означает, что проблема не в C #, а в более серьезной (хотя и странной) проблеме SQL Server. Один из парней из моей команды, который является отличным парнем из SQL, смотрит на путь выполнения sproc при запуске без предварительного копирования параметров. Если мы разберемся, я выложу ответ здесь. Спасибо за помощь!

Answer 1

Это, несомненно, случай перехвата параметров и неправильного повторного использования планов выполнения, которые были созданы с другим набором параметров, которые имели очень разную оптимальную схему доступа.

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

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

Причина, по которой ваша настройка параметров в SP устранила проблему, заключается в том, что SQL Server узнал, что вы что-то делаете с параметрами, задавих какое-то значение (игнорируя то, что вы задали бы им), и ему пришлось вычислить новый план выполнения, поэтому он выбросил старый и разработал новый путь доступа на основе набора параметров current , получая лучшие результаты.

Если эта проблема не исчезнет, ​​то игра с перекомпиляцией SP / очисткой кэша плана в сочетании с использованием различных параметров, которые должны работать с чрезвычайно различным числом строк, может выявить, где проблема.Посмотрите на план выполнения, который используется для запуска SP с разными параметрами, и посмотрите, как разные стратегии доступа используются в неправильных условиях.