Sqlserver
 sql >> Baza danych >  >> RDS >> Sqlserver

5 składni SQL i zasad zapytań dla lepszego monitorowania baz danych

Przyjęcie dobrej składni SQL i praktyk pisania zapytań poprawi skuteczność monitorowania bazy danych, a w rezultacie poprawi ogólną wydajność bazy danych. Istnieje kilka wypróbowanych i sprawdzonych sposobów na poprawę wydajności bazy danych poprzez dostosowanie składni i zapytań. Wybraliśmy 5, na których się skupiliśmy.

1. Wyrażenia CASE

Oto kilka sprawdzonych metod uzyskiwania najlepszej wydajności z wyrażeń CASE:

  • Wyrażenia CASE poprawiają wydajność, przenosząc stary kod proceduralny do kodu deklaratywnego, który można następnie zoptymalizować. W przypadku podstawowych wyrażeń CASE użyj , który jest najłatwiejszy do optymalizacji. W przypadku rozszerzonych wyrażeń CASE najbardziej przydatne będą skróty i inne techniki.
  • Ponieważ KIEDY klauzule są testowane od lewej do prawej, najlepiej jest ułożyć klauzule tak, aby najbardziej prawdopodobne były wymienione jako pierwsze. Pozwoli to skrócić czas poświęcany na niepotrzebne skanowanie.
  • Większość optymalizatorów uwzględnia również nadmiarowe testy, biorąc pod uwagę kolejność wykonywania. Po wykonaniu klauzuli WHEN nie ma potrzeby ponownego testowania tej klauzuli. Jednak wiele optymalizatorów nie radzi sobie dobrze z odczytywaniem zagnieżdżonych wyrażeń CASE, więc najlepiej jest spłaszczyć je do jednego poziomu.

2. Podwójne zanurzenie i klauzula okienkowa

W SQL „podwójne zanurzanie” oznacza odwiedzanie tej samej tabeli więcej niż jeden raz, co spowalnia twoje zapytanie. Najlepiej, jeśli spróbujesz wykonać wszystkie swoje zadania podczas jednej wizyty przy stole. Ale jeśli nie jest to możliwe, istnieje kilka sposobów na złagodzenie wpływu na wydajność.

Używanie tabel tymczasowych zbudowanych z tej samej tabeli bazowej połączonych ze sobą naprawdę nie jest najlepszym sposobem na uniknięcie podwójnego zanurzania. Lepszym rozwiązaniem jest użycie optymalizatora silnika SQL do wyświetlania WIDOKÓW i udostępniania wyników jako tabeli roboczej.

Jeśli jesteś ograniczony do mniej niż gwiezdnego optymalizatora, użyj tabel tymczasowych i wykonaj pracę ręcznie.

Chociaż powyższe metody są całkowicie akceptowalne, najlepszym sposobem na uniknięcie podwójnego wstawiania jest użycie klauzuli window, ponieważ klauzule podrzędne działają podobnie do funkcji podzapytania. Na przykład:

  • Klauzula PARTITION BY jest jak lokalna GROUP BY, która dzieli tabelę na grupy.
  • Klauzula ORDER BY narzuca porządek posortowany.
  • Ramka okna (ROW lub RANGE) jest jak lokalna klauzula WHERE.

Możesz zoptymalizować funkcje okna, przestrzegając następujących reguł:

  • W indeksie posortuj najpierw kolumny klauzuli PARTITION BY, a następnie kolumny użyte w klauzuli ORDER BY.
  • Uwzględnij każdą inną kolumnę, do której odwołuje się zapytanie, jako uwzględnione kolumny indeksu.

3. Użyj procedur zapisanych

Mapery obiektowo-relacyjne (ORM) powodują liczne problemy z wydajnością podczas generowania własnego kodu. Jeśli musisz korzystać z ORM, napisz własne procedury składowane, aby wydajność nie ucierpiała.

Istnieje wiele sposobów na poprawę wydajności przy użyciu procedur składowanych, w tym:

  • Przesyłają mniej danych w sieci, dzięki czemu transakcje są szybsze
  • Pozwalają na krótsze połączenia
  • Procedury przechowywane są łatwiejsze do śledzenia w narzędziach profilu
  • Ponieważ procedura składowana jest rzeczywistym obiektem w Twojej bazie danych, łatwiej jest uzyskać statystyki wydajności, co ułatwia znajdowanie problemów z wydajnością
  • Wzrost ponownego wykorzystania planu wykonania
  • Ułatwiają radzenie sobie z przypadkami brzegowymi i dodają zachowanie audytu lub blokowania zmian
  • Procedury przechowywane nie są podatne na ataki typu SQL injection

4. USUŃ i AKTUALIZUJ w partiach

Usuwanie lub aktualizowanie dużej ilości danych ze skanowania dużej tabeli wymaga dużej ilości zasobów, ponieważ obie instrukcje są uruchamiane jako pojedyncza transakcja. Jest to zabójca wydajności, ponieważ jeśli wystąpi błąd podczas wykonywania transakcji i musisz go zatrzymać, system musi wycofać całą transakcję. Wycofywanie dużych ilości danych zajmuje dużo czasu i blokuje inne transakcje.

Możesz uniknąć tego problemu z wydajnością, wykonując aktualizacje i usuwanie w małych partiach. Po uruchomieniu tych transakcji w partiach, jeśli transakcja zostanie zabita, wycofanie jest znacznie mniejsze. Wycofanie niewielkiej ilości danych nie zajmuje dużo czasu, a inne transakcje mogą działać, gdy partia jest zapisywana na dysku.

5. Nie pobieraj więcej kolumn niż potrzebujesz

Jedną z głównych przyczyn niskiej wydajności zapytań jest pobieranie zbędnych kolumn. Unikaj praktyk, które często powodują zwracanie nadmiernej liczby kolumn. Pamiętaj o następujących kwestiach:

  • Niepotrzebne użycie „SELECT *” w zapytaniu prawdopodobnie zwróci więcej kolumn niż potrzebujesz. Jest to marnowanie zasobów i blokowanie zasobów innych użytkowników. Szczególnie ważne jest, aby nie używać bezkrytycznie „SELECT *” w kolumnowych bazach danych SQL.
  • Wykonywanie operacji wycinania i wklejania w celu ponownego użycia kodu może skutkować pojawieniem się nieistotnych kolumn.
  • Kiedy wywołujesz WIDOK, możesz otrzymać zagnieżdżone kolumny. Rozpakuj słabo działające zapytania, aby sprawdzić, które kolumny tam są, i pozbądź się kolumn o zbyt dużym rozmiarze, których nie potrzebujesz. Dobrą wskazówką, że masz problem jest to, że masz klauzulę WHERE z dodatkowymi warunkami i klauzulę FROM z dodatkowymi sprzężeniami zewnętrznymi.

To tylko kilka sposobów, w jakie sumienne podejście do składni SQL i pisania zapytań może usprawnić monitorowanie bazy danych. Nie bój się próbować innych. Wysokowydajna baza danych jest kluczem do osiągnięcia celów biznesowych w każdej organizacji.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Oblicz całkowity koszt monitorowania serwera SQL

  2. Porównanie dat zapisanych jako varchar

  3. Uwagi na temat edycji SQL Server 2019

  4. Wyświetlanie historii zadań agenta programu SQL Server za pomocą usługi Azure Data Studio

  5. sp_add_schedule vs sp_add_jobschedule w programie SQL Server:jaka jest różnica?