Podczas pisania zapytań lub kodu bazy danych SQL Server (procedury i widoki) zawsze zaleca się zwrócenie uwagi na plan wykonania. Powodów jest kilka. Po pierwsze – optymalizator może wybierać plan, którego się nie spodziewasz. Na przykład indeksowanie dużej tabeli przed dopasowaniem do mniejszej tabeli. Po drugie – należy zastanowić się, jak to zapytanie będzie działać w nadchodzących miesiącach lub latach, jeśli zapytania będą działały w nowym systemie z małymi tabelkami, które będą rosły. I na koniec, ale najważniejsze, jak szybko jest to zapytanie i ile zasobów zużywa. Ostatni punkt może nie wydawać się aż tak ważny, możesz myśleć, że wystarczy mniej niż 3 sekundy, ale gdyby udało się uruchomić w <1 s, czy nie byłoby lepiej? Jeśli Twoje bazy danych są hostowane w chmurze, zmniejszenie zasobów może również zaoszczędzić pieniądze.
Wiele przypadków optymalizacji SQL zwykle wynika z problemu wykrytego przez użytkownika końcowego lub oprogramowanie monitorujące. „Dlaczego wygenerowanie tego raportu zajmuje 30 minut?”, „Co powoduje wzrost oczekiwania we/wy” lub „Dlaczego te zadania trwają dwa razy dłużej niż w zeszłym roku?”
We wszystkich tych scenariuszach nadal sprowadza się do pewnej wiedzy na temat planów wykonania i najlepszego sposobu naprawy SQL w celu poprawy sytuacji, co może być bardzo czasochłonne i nie zawsze skuteczne.
Weźmy przykład. Piszesz więc nowe zapytanie, wykonujesz je, a potem myślisz, ojej, to trwa zbyt długo.
17 sekund na 730 rzędów, co mam zrobić?
Najpierw przejrzyjmy plan wykonania:
Nie zawsze jest to proste, jeśli musisz powiększać i pomniejszać, aby to zrozumieć. Tak więc pierwszą radą jest zdobycie dobrej przeglądarki planów, takiej jak ta, z pakietem dostrajania Spotlight.
Przeglądarka planu podświetla kluczowe fragmenty informacji, których potrzebujemy i gdzie znajdują się główne operacje, a także podświetla wszelkie ostrzeżenia.
Oto przykład:
Wystąpił problem z tym kodem, ale co możemy z tym zrobić?
Cóż, właściwie całkiem sporo. Moglibyśmy skorzystać z podpowiedzi do zapytań, przyjrzeć się dodaniu indeksów (nie zapominaj, że może to mieć wpływ na inne zapytania i DML), dodając fragmenty kodu, które nie zmieniają zestawu wyników, ale wpływają na optymalizację, aby wygenerować inny plan i małe sztuczki do zatrzymaj optymalizator biorąc pod uwagę konkretny indeks, którego używa i być może wygeneruj nowy plan. Ale to wszystko odbywa się metodą prób i błędów, a ręczne wykonanie jest bardzo czasochłonne.
Dodając aplikację Spotlight Extensions do SSMS i subskrybując pakiet Spotlight Tuning Pack, możemy pozwolić, aby funkcja optymalizacji w pakiecie Tuning Pack wykonała za nas całą ciężką pracę.
Być może zauważyłeś na pierwszym zrzucie ekranu, że gdy funkcja jest włączona, automatycznie wykrywa, że optymalizacja jest możliwa:
Kliknij Wyświetl analizę
Następnie możesz kliknąć przycisk Optymalizuj, a silnik optymalizatora przeanalizuje kod i zacznie stosować reguły przepisywania, które zmienią składnię SQL, dając alternatywy, które zapewniają ten sam zestaw wyników, a następnie przetestują je, abyśmy mogli zobaczyć, czy jest jakieś alternatywne wykonanie plany są szybsze i dlaczego. Reguły są stosowane w kombinacjach, więc możliwych alternatyw może być ponad 100. Jednak narzędzie pokazuje tylko alternatywy, które są szybsze niż oryginał.
Ten proces działa w tle i oszczędza ogromną ilość czasu, jeśli spróbujesz zrobić to ręcznie.
A po wyświetleniu wyników możesz porównać alternatywy, zobaczyć różnice w kodzie, porównać plany i przejrzeć statystyki.
Więc wróć do SSMS z moją nową wersją zapytania i przetestuj ją.
Sukces.
Jeśli jest to środowisko programistyczne, warto rozważyć opróżnienie pamięci podręcznej bufora za pomocą polecenia DBCC DROPCLEANBUFFERS, aby przetestować zapytania za pomocą zimnej pamięci podręcznej bufora bez wyłączania i ponownego uruchamiania serwera.
Rozważ również dodanie SET STATISTICS IO ON do zapytania, aby uzyskać więcej informacji o tym, dlaczego składnia zapytania zrobiła różnicę:
Oryginał:
Przepisz:
Można to również osiągnąć w pakiecie Tuning Pack z funkcją porównywania statystyk:
Tak więc, po udanej zmianie i zadowolonym użytkowniku końcowym, przejdź do następnego zapytania. Stale poprawiając wydajność poszczególnych zapytań, poprawiamy wydajność instancji.
