Łatwo jest zacząć majstrować przy narzędziach optymalizacji zapytań SQL. Otwierasz SQL Server Management Studio (SSMS), monitorujesz czas oczekiwania, przeglądasz plan wykonania, zbierasz informacje o obiektach i zaczynasz optymalizować SQL, aż uruchomisz dokładnie dostrojoną maszynę.
Jeśli jesteś w tym wystarczająco dobry, odniesiesz szybkie zwycięstwo i wrócisz do swojego regularnie zaplanowanego chaosu. Ale jeśli zmienisz niewłaściwą rzecz lub zmienisz właściwą rzecz w złym kierunku, cóż, nadeszła twoja środa.
Optymalizacja zapytań SQL? Co sprawia, że myślisz, że tego potrzebujesz?
W większości przypadków jest to wzrost liczby zgłoszeń problemów lub skarg użytkowników. „Dlaczego system jest tak powolny?” Twoi użytkownicy narzekają. „Wygenerowanie naszych zwykłych raportów w tym tygodniu zabiera nam wieczność”.
To oczywiście dość niejasny opis. Byłoby miło, gdyby mogli ci powiedzieć:„Wszystko jest powolne, ponieważ masz niejawną konwersję w wierszu 62. CurrentOrderQuery5.sql. Kolumna to varchar, a ty podajesz liczbę całkowitą. Ale jest mało prawdopodobne, że Twoi użytkownicy widzą ten poziom szczegółowości.
Przynajmniej zgłoszenia problemów i rozmowy telefoniczne stanowią aktywny wskaźnik:łatwy do zauważenia, łatwy do zmierzenia. Kiedy zaczną się pojawiać, możesz być pewien, że nadszedł czas na dostrojenie SQL.
Ale istnieją inne, pasywne wskaźniki, które sprawiają, że potrzeba jest mniej jasna. Rzeczy takie jak spadek sprzedaży, który może wynikać z wielu czynników. Czy to dlatego, że boleśnie powolne zapytania w Twoim sklepie internetowym sprawiają, że Twoi klienci porzucają koszyki? Czy to dlatego, że gospodarka jest w złym stanie?
Mogą to być również takie rzeczy, jak słaba wydajność SQL Server. Czy to dlatego, że źle napisane zapytanie wysyła odczyty logiczne przez dach? Czy to dlatego, że serwer ma mało zasobów fizycznych, takich jak pamięć i pamięć masowa?
W obu scenariuszach optymalizacja zapytań SQL może pomóc w przypadku pierwszej opcji, ale nie drugiej.
Dlaczego zastosować właściwe rozwiązanie niewłaściwego problemu?
Zanim pójdziesz ścieżką optymalizacji, upewnij się, że strojenie jest właściwym rozwiązaniem właściwego problemu.
Dostrajanie SQL jest procesem technicznym, ale każdy krok techniczny ma korzenie w sensie biznesowym. Możesz spędzić wiele dni próbując skrócić czas wykonania o kilka milisekund lub zmniejszyć liczbę odczytów logicznych o pięć procent, ale czy ta redukcja jest warta twojego czasu? To prawda, że spełnienie wymagań użytkowników jest ważne, ale każdy wysiłek w końcu osiąga punkt zmniejszania się zysków.
Rozważ te problemy z wydajnością zapytań SQL i otaczający je kontekst biznesowy:
- Dopuszczalna wydajność — Wykonanie zapytania zajmuje 10 minut, a użytkownik chce, aby zostało ono wykonane w ciągu jednej minuty; wydaje się to rozsądną rozbieżnością i osiągalnym celem optymalizacji. Jeśli jednak zapytanie trwa przez noc, a użytkownik uważa, że powinno zostać uruchomione w ciągu jednej minuty, może to oznaczać coś więcej niż problem ze strojeniem. Po pierwsze, może być konieczne poinformowanie użytkownika o ilości pracy, jaką faktycznie wykonuje zapytanie. Po drugie, może to być problem ze sposobem zaprojektowania bazy danych lub sposobem napisania aplikacji klienckiej.
- Narzędzie — Załóżmy, że odpowiadasz za administrowanie bazą danych finansowych w firmie produkcyjnej. Pod koniec każdego miesiąca użytkownicy narzekają na słabą wydajność. Śledzisz problem w serii raportów sporządzanych na koniec miesiąca przez dział księgowości, z których każdy zajmuje kilka godzin i trafia prosto do szafki na akta, której nikt nie zbadał. Zamiast dostrajania, wyjaśnij problem menedżerom biznesowym i uzyskaj pozwolenie na usunięcie raportów.
- Zmiana czasu — Albo załóżmy, że te same raporty są ważne dla zarządzania, ale nie pilne dla firmy. Jeśli są uruchamiane raz w tygodniu lub w miesiącu, można je zaplanować poza godzinami szczytu, wstępnie buforując zestaw danych i wysyłając wyniki do pliku. To usuwa wąskie gardło dla innych użytkowników biznesowych i uwalnia użytkownika księgowości od konieczności czekania na raporty.
Kiedy uwzględnisz kontekst biznesowy w swojej decyzji dotyczącej optymalizacji, możesz ustalić priorytety i kupić sobie czas.
Gdy optymalizujesz zapytania SQL, wypróbuj diagramy SQL
SSMS i narzędzia wbudowane w SQL Server oferują większość tego, czego potrzebujesz do efektywnej optymalizacji zapytań SQL. Połącz narzędzia z metodycznym podejściem wokół następujących kroków, jak opisano w e-booku „Podstawowy przewodnik po optymalizacji zapytań SQL”:
- Monitoruj czas oczekiwania
- Przejrzyj plan wykonania
- Zbierz informacje o obiekcie
- Znajdź stół kierowcy
- Zidentyfikuj inhibitory wydajności
W kroku 4 Twoim celem jest kierowanie zapytaniem przy użyciu tabeli, która zwraca najmniej danych. Kiedy badasz sprzężenia i predykaty i filtrujesz wcześniej w zapytaniu, a nie później, zmniejszasz liczbę logicznych odczytów. To duży krok w optymalizacji zapytań SQL.
Diagramy SQL to graficzna technika mapowania ilości danych w tabelach i znajdowania, który filtr zwróci najmniej rekordów. Najpierw określasz, które tabele zawierają szczegółowe informacje, a które są tabelami głównymi lub tabelami przeglądowymi. Rozważ prosty przykład tego zapytania w bazie danych rejestracji uczelni:
Szczegółowa tabela to rejestracja. Ma dwie tabele przeglądowe, ucznia i klasy. Aby zobrazować te tabele, narysuj odwrócone drzewo łączące tabelę szczegółów (u góry) za pomocą strzałek (lub linków) z tabelami przeglądowymi, tak jak to:
Teraz oblicz względną liczbę rekordów wymaganych dla kryteriów łączenia (czyli średni stosunek wierszy powiązanych między tabelą szczegółów a tabelami przeglądowymi). Napisz liczby na każdym końcu strzałki. W tym przykładzie na każdego ucznia w tabeli rejestracji przypada około 5 rekordów, a dla każdej klasy jest około 30 rekordów w rejestracji. Oznacza to, że nigdy nie powinno być konieczne DOŁĄCZENIE do więcej niż 150 (5×30) rekordów, aby uzyskać wynik dla pojedynczego ucznia lub jednej klasy.
To ćwiczenie jest przydatne, jeśli Twoje kolumny sprzężenia nie są indeksowane lub jeśli nie masz pewności, że są indeksowane.
Następnie spójrz na predykaty filtrowania, aby znaleźć tabelę, z którą należy kierować zapytanie. To zapytanie miało dwa filtry:jeden w przypadku anulowania rejestracji =„N”, a drugi w dniu rejestracji_data między dwiema datami. Aby zobaczyć, jak selektywny jest filtr, uruchom to zapytanie podczas rejestracji:
wybierz count(1) z rejestracji, gdzie anulowano =„N”
ORAZ r.signup_date POMIĘDZY :data_początkowa ORAZ :data_początkowa +1
Zwraca 4344 rekordy z 79 800 wszystkich rekordów w rejestracji. Oznacza to, że 5,43 procent rekordów zostanie odczytanych przez ten filtr.
Drugi filtr jest w klasie:
wybierz count(1) z klasy, gdzie nazwa =‘ENGLISH 101’
Zwraca dwa rekordy na 1000, czyli 0,2 procent, co stanowi znacznie bardziej selektywny filtr. Zatem klasa jest tabelą kierującą i tą, na której należy najpierw skupić się na dostrajaniu SQL.
Głos użytkownika
Jeśli masz pewność, że potrzebujesz dostrajania SQL, „Podstawowy przewodnik po optymalizacji zapytań SQL” zawiera dodatkowe informacje. Przeprowadzi Cię przez pięć wskazówek dotyczących dostrajania wydajności za pomocą zapytań typu „kopiuj i wklej” oraz studiów przypadku, w tym opisanego powyżej.
Prawdopodobnie przekonasz się, że najważniejszym narzędziem do optymalizacji zapytań SQL jest głos użytkownika. Czemu? Ponieważ ten głos informuje, kiedy rozpocząć optymalizację i informuje, kiedy zoptymalizowałeś wystarczająco. Może zapewnić, że zaczniesz majstrować przy biegach, kiedy zajdzie taka potrzeba, i zatrzymasz się, gdy jesteś jeszcze przed nami.
