Wydajność planu wykonania słabej procedury składowanej SQL - wąchanie parametrów

Mam procedurę składowaną, która akceptuje dane wejściowe daty, które są później ustawione na bieżącą datę, jeśli żadna wartość nie zostanie przekazana:

<code>CREATE PROCEDURE MyProc
    @MyDate DATETIME = NULL
AS
    IF @MyDate IS NULL SET @MyDate = CURRENT_TIMESTAMP
    -- Do Something using @MyDate
</code>

Mam problemy, przez co jeśli@MyDate jest przekazywane jakoNULL gdy procedura składowana jest po raz pierwszy kompilowana, wydajność jest zawsze straszna dla wszystkich wartości wejściowych (NULL lub inaczej), jeśli data / bieżąca data jest przekazywana, gdy procedura składowana jest skompilowana, wydajność jest dobra dla wszystkich wartości wejściowych (NULL lub w przeciwnym wypadku).

Mylące jest również to, że generowany w słabym planie wykonania jest straszny, nawet jeśli użyta wartość @MyDate totak właściwie NULL (i nie ustawione naCURRENT_TIMESTAMP przez instrukcję IF)

Odkryłem, że wyłączenie wąchania parametrów (podszywając parametr) rozwiązuje mój problem:

<code>CREATE PROCEDURE MyProc
    @MyDate DATETIME = NULL
AS
    DECLARE @MyDate_Copy DATETIME
    SET @MyDate_Copy = @MyDate
    IF @MyDate_Copy IS NULL SET @MyDate_Copy = CURRENT_TIMESTAMP
    -- Do Something using @MyDate_Copy
</code>

Wiem, że to ma coś wspólnego z wąchaniem parametrów, ale wszystkie przykłady, które widziałem w "sniffing parametru poszło źle", wymagały skompilowania procedury przechowywanej z niereprezentatywnym parametrem, jednak tutaj widzę, że plan wykonania jest straszny dla wszystkich możliwych wartości, które serwer SQL może uważać za ten parametr w momencie wykonania instrukcji -NULL, CURRENT_TIMESTAMP lub w przeciwnym wypadku.

Czy ktoś ma wgląd w to, dlaczego tak się dzieje?

questionAnswers(2)

yourAnswerToTheQuestion