Jedną z najlepszych części języka SQL jest to, że łatwo jest się go nauczyć i podążać za poleceniami, a wszystko to dzięki prostej składni.

Ale tutaj jest haczyk: nie wszystkie funkcje baz danych są wydajne. Dwa zapytania mogą wyglądać podobnie, ale różnić się pod względem czasu obliczeniowego, a to właśnie robi różnicę. Dlatego właśnie dostrajanie zapytań SQL jest niezbędne.

Jeśli jesteś organizacją, która używa produkcyjnej bazy danych do celów raportowania i pozyskiwania aktualnych danych, optymalizacja zapytań SQL jest jeszcze ważniejsza, aby uniknąć niepotrzebnego obciążania zasobów produkcyjnej bazy danych.

Ways to Fine Tune Your SQL Queries

Have a clear set of business requirements before you begin

Jednym z najlepszych sposobów na optymalizację zapytań SQL jest robienie właściwych rzeczy od samego początku. Dlatego zanim zaczniesz, upewnij się, że zaznaczyłeś następujące pola:

Czy rozpoznałeś odpowiednich interesariuszy?

Niezbędne jest zaangażowanie wszystkich odpowiednich osób i zespołów podczas tworzenia zapytania. Dodatkowo, ważne jest również, aby zaangażować zespół DBA podczas tworzenia zapytań do produkcyjnych baz danych.

Czy zidentyfikowałeś swoje wymagania?

Najlepszą praktyką, aby zapewnić, że wszystkie wymagania są spełnione jest udzielenie odpowiedzi na 5 zestawów pytań – Kto? Dlaczego? Co? Kiedy? Gdzie?

Czy zidentyfikowane wymagania są specyficzne i w punkt?

Produkcyjna baza danych odgrywa kluczową rolę. Obciążanie jej niejednoznacznymi wymaganiami jest zbyt ryzykowne. Tak więc, przed uruchomieniem zapytania, upewnij się, że wszystkie wymagania są specyficzne i przedyskutowane z odpowiednimi interesariuszami

Opanuj sztukę tworzenia indeksów poprawnie

Performance tuning w SQL może być wykonany poprzez odpowiednie indeksowanie, co przekłada się na szybszy dostęp do bazy danych w krytycznych momentach. Jest to jeden z obszarów, w którym większość początkujących użytkowników baz danych ponosi porażkę. Próbują oni albo indeksować wszystko, albo nie indeksować niczego, a żadne z tych podejść nie działa na ich korzyść.

Jest to spowodowane tym, że kiedy nie wykonasz żadnego indeksowania, twoje zapytania będą działać wolno i niepotrzebnie obciążać bazę danych. Z drugiej strony, jeśli indeksujesz wszystko, twoje triggery insert nie będą działały zgodnie z oczekiwaniami, czyniąc twoją bazę danych nieefektywną. Kluczem jest tutaj znalezienie odpowiedniej równowagi.

Unikaj używania SELECT*

SELECT* (czytaj jako select all) jest często używany jako skrót do zapytania o wszystkie dane z tabeli. Chociaż ta metoda działa dobrze w przypadku mniejszych tabel, obciąża ona niepotrzebnie zasoby bazy danych, gdy zapytanie jest wykonywane do tabeli z wieloma polami i wierszami.

Najlepszym sposobem jest zdefiniowanie pól w instrukcji SELECT, aby poinstruować bazę danych do odpytywania tylko tych danych, które są wymagane do osiągnięcia celów końcowych.

Zrozummy to lepiej na przykładzie:

Jest to nieefektywny sposób, ponieważ zapytanie to pobierze wszystkie dane przechowywane w tabeli Users niezależnie od potrzeb.

SELECT*

FROM Users

Jest to bardziej efektywny sposób zapytania, ponieważ pobiera tylko wymagane informacje i zapobiega obciążeniu bazy danych.

SELECT LastName, Address, Contact

FROM Users

Mądrze używaj tabel tymczasowych

Mimo, że tabele tymczasowe są świetne w użyciu, zwiększają złożoność zapytania wykładniczo. Zaleca się unikanie korzystania z tabel tymczasowych, jeśli kod może być napisany w prosty sposób.

Jednakże, jeśli masz do czynienia z procedurą składowaną, która nie może być obsłużona przez pojedyncze zapytanie, korzystanie z tabel tymczasowych jako pośredników może zakończyć twoje problemy.

Unikaj używania COUNT()

Jednym z powszechnych sposobów, dzięki którym programiści sprawdzają czy dany rekord istnieje jest użycie COUNT() zamiast EXISTS(). COUNT() jest nieefektywne, ponieważ skanuje całą tabelę i zlicza wszystkie zapytania, które spełniają warunek. Z drugiej strony, EXISTS() jest bardziej wydajne, ponieważ kończy pętlę, gdy tylko zauważy pożądany wynik. Przyczynia się to do lepszego działania i sprawia, że kod jest bardziej schludny.

Unikaj używania znaków wieloznacznych na początku wzorca LIKE

Aby dostroić swoje zapytania SQL, musisz unikać używania wzorca LIKE w następujący sposób:

SELECT* FROM Customers WHERE address LIKE ‘%bar%’;

W tym przypadku baza danych nie będzie w stanie użyć odpowiedniego indeksu, jeśli istnieje on z powodu % znaku wieloznacznego. System zaczyna od wykonania pełnego skanowania tabeli, a to zbiera żniwo na jego prędkości. Tak więc, lepszym sposobem na napisanie tego zapytania jest:

SELECT* FROM Customers WHERE address LIKE ‘bar%’;

Unikaj używania SELECT DISTINCT

Ale możesz łatwo wyeliminować duplikaty z zapytania używając SELECT DISTINCT, ta funkcja zużywa znaczną ilość mocy obliczeniowej. Co więcej, zapytanie to działa poprzez grupowanie wszystkich pól w zapytaniu w celu przedstawienia odrębnych wyników. To z kolei sprawia, że jest ono wysoce niedokładne.

Najlepszym sposobem na uniknięcie zduplikowanych rekordów w zapytaniu jest dodanie większej ilości pól. W ten sposób, nie będzie potrzeby grupowania, a pobrane rekordy będą dokładne.

Na przykład, oto nieefektywny sposób na zrobienie tego:

SELECT DISTINCT FirstName, LastName, State

FROM Users

A oto efektywny sposób na zrobienie tego:

SELECT FirstName, LastName, Contact, Address, State, Zip

FROM Users

Porada bonusowa: Zachowaj niektóre zapytania na czasy poza szczytem

Aby upewnić się, że Twoja produkcyjna baza danych pozostaje bezpieczna i zdrowa, wysoce zalecane jest zaplanowanie niektórych zapytań na czasy poza szczytem, idealnie, gdy liczba współbieżnych użytkowników jest najniższa. Tak więc, środek nocy, 3-5 rano. jest najlepszym czasem na wykonywanie takich zapytań jak:

• Zapisy pętlowe
• Uruchamianie SELECT* na dużych tabelach z ponad 1 milionem rekordów
• Zagnieżdżone podzapytania
• Wildcard searches

.

• CROSS JOINs
• SELECT DISTINCT statements

The Wrap Up

Dostrajanie wydajności w SQL jest ważne, aby utrzymać bazę danych w dobrym stanie, ale nie jest to najłatwiejsze zadanie do wykonania. Wydajność zapytań SQL zależy od wielu czynników, takich jak model bazy danych, rodzaj informacji, które muszą być pobrane i tak dalej.

Zaleca się unikanie kłopotliwych sytuacji poprzez śledzenie wszystkich zapytań, które wkrótce zostaną odpalone i dostarczanie najlepszych rozwiązań. Jako DBA, możesz również wyposażyć programistów w pulpit nawigacyjny oparty na danych, dzięki czemu nie muszą oni odpalać zapytań teraz i później, aby pobrać niezbędne informacje. Oto niesamowity artykuł o tym, jak można stworzyć pulpit SQL, który pobiera dane bezpośrednio z bazy danych.

Jakie są Twoje poglądy na ten temat? Jak dostrajasz swoje zapytania SQL? Daj nam znać.