SQL wykonanie planu biedny procedura przechowywana wydajność - parametr wąchania

Question

Mam procedurę przechowywaną, która akceptuje wejście datę, która jest później zestaw do bieżącej daty, jeśli wartość nie jest przekazywana w:

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

Mam problemy przy czym jeśli @MyDate jest przekazywany jako NULL, gdy procedura składowana jest najpierw kompilowana, wydajność jest zawsze straszna dla wszystkich wartości wejściowych (NULL lub w inny sposób), lub jeśli data/aktualna data jest przekazywana podczas kompilacji procedury składowanej, wydajność jest grzywny dla wszystkich wartości wejściowych (NULL lub w inny sposób).

Co jest również mylące jest to, że biedny plan wykonania, który jest generowany w jest straszna nawet gdy wartość @MyDate stosowany jest faktycznieNULL (a nie ustawione CURRENT_TIMESTAMP sprawozdaniem if)

I wcześniej odkryto, że wyłączenie parametr wąchania (o fałszowanie parametr) rozwiązuje mój problem:

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 

wiem, że to ma coś wspólnego z parametrem wąchania, ale wszystkie przykłady widziałem od „parametru wąchania gone bad” włączyłem procedurę przechowywaną ing skompilowany z niereprezentatywnym parametrem przekazywanym, jednak widzę, że plan wykonania jest okropny dla wszystkich możliwych wartości, które serwer SQL mógłby uznać za parametr, który może zająć w miejscu, w którym instrukcja jest wykonywana - NULL, lub w inny sposób .

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

Answer 1

Zasadniczo tak - sniffowanie parametrów (w niektórych poziomach poprawek) SQL Server 2005 jest poważnie uszkodzony. Widziałem plany, które nigdy nie kończą się (w ciągu kilku godzin na małym zbiorze danych) nawet dla małych (kilka tysięcy rzędów) zestawów danych, które kończą się w kilka sekund po maskowaniu parametrów. I to w przypadkach, gdy parametr zawsze był tą samą liczbą. Chciałbym dodać, że w tym samym czasie miałem do czynienia z tym, znalazłem wiele problemów z LEFT JOIN/NULLs nie kończących się i zastąpiłem je NOT IN lub NOT EXISTS i to rozwiązało plan do czegoś, co mogłoby się skończyć. Ponownie, (bardzo słaby) problem z planem wykonania. W tym czasie miałem do czynienia z tym, DBAs nie dałby mi dostęp do programu SHOWPLAN, a ponieważ zacząłem maskować każdy parametr SP, nie miałem żadnych dalszych problemów z planem wykonania, gdzie musiałbym się do tego zagłębić za brak ukończenia .

W SQL Server 2008 można użyć OPTIMIZE FOR UNKNOWN.

Answer 2

Jednym ze sposobów, w jaki udało mi się obejść ten problem (SQL Server 2005), a nie tylko maskowanie parametrów przez redeclaring lokalnych parametrów było dodanie wskazówek optymalizatora zapytań.

Tutaj jest dobrym blogu, który mówi więcej o tym: Parameter Sniffing in SqlServer 2005

użyłem: OPCJA (optymalizacja pod kątem (@p = '-1'))