WYBIERZ TOP 1 szkodzi wydajności zapytania; czy jest dostępny sposób na rozwiązanie problemu przez dba?


13

W aplikacji produkcyjnej (C # rozmawiającej z SQL Server 2014 Standard) jest zapytanie, które wygląda tak jak poniżej. Przez większość czasu działa w milisekundach. Ale czasami (dla niektórych wartości @Id) szaleje i zajmuje około minuty. Jest to czas dłuższy niż limit czasu aplikacji, więc aplikacja nie działa dla użytkownika.

W przypadkach „szaleje” zwrócony zestaw wyników jest poprawnie pusty, podobnie jak w wielu, ale nie we wszystkich innych przypadkach.

Na szczęście jest to powtarzalne zarówno w środowisku produkcyjnym, jak i programistycznym.

Deweloper mówi, że usunięcie „TOP 1” z zapytania, a następnie upewnienie się, że aplikacja zużywa dodatkowe wiersze zestawu wyników, rozwiązuje problem z wydajnością.

Planer zapytań sugeruje brak indeksów, gdy TOP 1jest obecny. (w dev).

Trwa zmiana zapytania i naprawa aplikacji. Wdrożenie zajmuje trochę czasu.

Moje pytanie: Czy istnieje jakikolwiek dostępny sposób DBA na dostrojenie lub ulepszenie produkcyjnej instancji SQL Server, aby rozwiązać ten problem, zanim aplikacja zmieni się wraz z wprowadzeniem nowego zapytania?

SELECT TOP 1
       subscription_id 
  FROM subscription AS sub
  JOIN billing_info AS bi ON bi.billing_info_id = sub.billing_info_id   
  JOIN person_group AS apg ON apg.person_id = bi.person_id
  JOIN pplan ON pplan.plan_id = sub.plan_id
  JOIN product ON product.product_id = [plan].product_id 
  JOIN product_attribute ON product_attribute.product_id = product.product_id 
 WHERE apg.group_id = @Id
   AND apg.start_date < GETDATE()
   AND (apg.end_date IS NULL OR apg.end_date > GETDATE()) 
   AND (sub.end_date IS NULL OR sub.end_date > GETDATE()) 
   AND product_attribute.attribute_type = 'special feature' 
   AND product_attribute.attribute_data = '1' 
 ORDER BY sub.start_date ASC;

Czy próbowałeś tego jako podzapytania? Np. Wybierz top 1
id_

Może zadziała jakieś „normalne” strojenie zapytania? Jeśli indeksy są wystarczająco atrakcyjne, skany znikają. To mniej inwazyjne niż przewodnik po planie.
usr

Czy te same wartości @ID zawsze powodują, że „wariuje”? Jeśli tak, przetestuj przy użyciu jednej z tych wartości i przechwyć aktualny plan zapytań. To powie ci, co się dzieje źle. Jeśli „złe” wartości nie są spójne, wydaje się prawdopodobne, że jest to albo sniffing parametrów (patrz rozwiązanie @ MartinSmith, aby uzyskać rozwiązanie), albo problem z blokowaniem związany z tym, jak klient faktycznie żąda i zużywa zestaw wyników.
RBarryYoung

Odpowiedzi:


12

Jeśli nie możesz zmienić zapytania, możesz skorzystać z przewodnika po planach.

Przetestuj wydajność zapytania za pomocą OPTION (QUERYTRACEON 4138)(będzie potrzebował kogoś z sysadminuprawnieniami, aby spróbować).

Jeśli daje to zadowalającą wydajność, możesz zastosować to z przewodnikiem planu. Jeśli nie daje zadowalającej wydajności, spróbuj znaleźć wskazówkę, która działa. Być może OPTION (HASH JOIN, MERGE JOIN)problem stanowią niewłaściwe zagnieżdżone pętle. Może być konieczne skorzystanie z USE PLAN N'...'podpowiedzi.

Po zapoznaniu się z wymaganymi wskazówkami możesz je zastosować, korzystając z informacji tutaj .


OPTION (QUERYTRACEON 4138)wykonał lewę. Dzięki. Teraz posortuj przewodniki po planach.
O. Jones,

0

dla uśmiechów spróbuj
to> zmienia się na> = więc nie dokładnie to samo zapytanie

SELECT TOP 1
       subscription_id 
  FROM subscription AS sub
  JOIN billing_info AS bi 
        ON bi.billing_info_id = sub.billing_info_id   
  JOIN person_group AS apg 
        ON apg.person_id = bi.person_id 
       AND apg.group_id = @Id
       AND apg.start_date < GETDATE()
       AND isnnull(apg.end_date, GETDATE()) >= GETDATE()             
  JOIN pplan 
        ON pplan.plan_id = sub.plan_id
       AND isnnull(sub.end_date, GETDATE()) >= GETDATE()
  JOIN product 
        ON product.product_id = [plan].product_id 
  JOIN product_attribute 
        ON product_attribute.product_id = product.product_id 
       AND product_attribute.attribute_type = 'special feature' 
       AND product_attribute.attribute_data = '1' 
 ORDER BY sub.start_date ASC;

„Trwa zmiana zapytania i naprawa aplikacji. Wdrażanie zajmuje trochę czasu.” OP szuka rozwiązania, które naprawi wydajność „tak jak jest”.
Martin Smith,

@MartinSmith A kiedy wprowadzą poprawkę, może to być lepsza poprawka. Doprowadzenie aplikacji do zużycia dodatkowych wierszy będzie innymi zmianami programu.
paparazzo
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.