Ulubione triki dostrajania wydajności

Oto poręczna lista rzeczy, które zawsze daję komuś, kto pyta mnie o optymalizację.
Głównie używamy Sybase, ale większość porad będzie miała zastosowanie we wszystkich obszarach.

Na przykład SQL Server zawiera wiele bitów do monitorowania/dostrajania wydajności, ale jeśli nie masz czegoś takiego (a może nawet jeśli masz), rozważę następujące...

99% problemów Widziałem, że są spowodowane umieszczeniem zbyt wielu tabel w połączeniu . Rozwiązaniem jest wykonanie połowy złączenia (z niektórymi tabelami) i buforowanie wyników w tabeli tymczasowej. Następnie wykonaj resztę kwerendy łączącej się z tą tabelą tymczasową.

Lista kontrolna optymalizacji zapytań

• Uruchom UPDATE STATISTICS w tabelach poniżej
  • Wiele systemów uruchamia to jako zaplanowane cotygodniowe zadanie
• Usuń rekordy z tabel podrzędnych (ewentualnie zarchiwizuj usunięte rekordy)
  • Rozważ robienie tego automatycznie raz dziennie lub raz w tygodniu.
• Odbuduj indeksy
• Odbuduj tabele (wyjście/wejście danych bcp)
• Zrzuć/przeładuj bazę danych (drastyczne, ale może naprawić uszkodzenie)
• Zbuduj nowy, bardziej odpowiedni indeks
• Uruchom DBCC, aby sprawdzić, czy istnieje możliwość uszkodzenia bazy danych
• Zamki / Zakleszczenia
  • Upewnij się, że w bazie danych nie działają żadne inne procesy
    • Zwłaszcza DBCC
  • Czy używasz blokowania na poziomie wiersza lub strony?
  • Zablokuj tabele wyłącznie przed rozpoczęciem zapytania
  • Sprawdź, czy wszystkie procesy uzyskują dostęp do tabel w tej samej kolejności
• Czy indeksy są używane właściwie?
  • Złączenia będą używać indeksu tylko wtedy, gdy oba wyrażenia mają dokładnie ten sam typ danych
  • Indeks będzie używany tylko wtedy, gdy pierwsze pola w indeksie zostaną dopasowane w zapytaniu
  • Czy indeksy klastrowe są używane tam, gdzie jest to właściwe?
    • dane zakresu
    • Pole WHERE między wartością1 a wartością2
• Małe łączenia to dobre łączenia
  • Domyślnie optymalizator bierze pod uwagę tylko 4 tabele na raz.
  • Oznacza to, że w przypadku złączeń z więcej niż 4 tabelami istnieje duża szansa na wybór nieoptymalnego planu zapytań
• Zerwij Dołącz
  • Czy możesz zerwać połączenie?
  • Wstępnie wybierz klucze obce do tabeli tymczasowej
  • Wykonaj połowę sprzężenia i umieść wyniki w tabeli tymczasowej
• Czy używasz odpowiedniego rodzaju tabeli tymczasowej?
  • #temp tabele mogą działać znacznie lepiej niż @table zmienne o dużej objętości (tysiące wierszy).
• Utrzymuj tabele podsumowań
  • Buduj z wyzwalaczami na bazowych tabelach
  • Buduj codziennie / co godzinę / itd.
  • Tworzenie ad hoc
  • Tworzenie przyrostowe lub niszczenie/przebudowywanie
• Zobacz, jaki jest plan zapytań z SET SHOWPLAN ON
• Zobacz, co się właściwie dzieje z SET STATS IO ON
• Wymuś indeks za pomocą pragmy:(index:myindex)
• Wymuś kolejność stołu za pomocą SET FORCEPLAN ON
• Wąchanie parametrów:
  • Podziel zapisaną procedurę na 2
  • wywołaj proc2 z proc1
  • pozwala optymalizatorowi wybrać indeks w proc2, jeśli @parametr został zmieniony przez proc1
• Czy możesz ulepszyć swój sprzęt?
• O której godzinie biegniesz? Czy jest spokojniejszy czas?
• Czy serwer replikacji (lub inny nieprzerwany proces) działa? Czy możesz to zawiesić? Uruchom go np. cogodzinny?