1. Aby zoptymalizować zapytanie, należy unikać pełnego skanowania tabel i najpierw rozważyć utworzenie indeksu na kolumnach w miejscu i kolejności pod.
2. Staraj się unikać oceny wartości zerowej dla pól w klauzuli where, w przeciwnym razie silnik porzuci użycie indeksów i wykona pełne skanowanie tabel, na przykład:
Wybierz id z T, gdzie num jest null
Możesz ustawić domyślną wartość 0 na numerze, upewnić się, że w kolumnie num w tabeli nie ma wartości null, a następnie zapytać w ten sposób:
wybierz id z T, gdzie num=0
3. Staraj się unikać używania operatorów != lub <> w klauzuli where, w przeciwnym razie silnik porzuci użycie indeksów i wykona pełne skanowanie tabel.
4. Powinieneś unikać używania OR w klauzuli where do dołączenia warunku, w przeciwnym razie silnik porzuci użycie indeksów i wykona pełne skanowanie tabeli, na przykład:
Wybierz id z T, gdzie num=10 lub num=20
Możesz zapytać w ten sposób:
Wybierz id z T, gdzie num=10
Union All
Wybierz id z T, gdzie num=20
5.in i nie w powinny być również stosowane ostrożnie, bo w przeciwnym razie doprowadzi to do pełnego skanowania tabeli, na przykład:
Wybierz id z T, gdzie num in(1,2,3)
Dla wartości ciągłych nie używaj in, jeśli możesz użyć pomiędzy:
Wybierz id z T, gdzie num między 1 a 3
6. Następujące zapytanie również skutkuje pełnym skanowaniem tabeli:
Wybierz id od T, gdzie nazwa typu '%abc%'
Aby zwiększyć efektywność, rozważ wyszukiwanie pełnotekstowe.
7. Jeśli użyjesz parametru w klauzuli where, spowoduje to również pełne skanowanie tabeli. Ponieważ SQL rozwiązuje tylko lokalne zmienne w czasie działania, ale optymalizator nie może przesunąć wyboru planów dostępu do czasu uruchomienia; Musi być wybrany podczas kompilacji. Jednak jeśli plan dostępu zostanie ustanowiony w czasie kompilacji, wartość zmiennej pozostaje nieznana i dlatego nie może być użyta jako element wejściowy do wyboru indeksu. Następujące oświadczenia zostaną zeskanowane w całości:
Wybierz id z T, gdzie num=@num
Możesz wymusić zapytanie do użycia indeksu:
Wybierz id z t with(index(index(index name)) gdzie num=@num
8. Staraj się unikać wyrażania pól w klauzuli where, co spowoduje, że silnik porzuci użycie indeksów na rzecz pełnego skanowania tabel. Na przykład:
Wybierz id z T, gdzie num/2=100
powinno się zmienić na:
Wybierz id z T, gdzie num=100*2
9. Staraj się unikać wykonywania operacji funkcyjnych na polach w klauzuli where, co spowoduje, że silnik porzuci użycie indeksów na rzecz pełnego skanowania tabel. Na przykład:
Wybierz ID z T, gdzie substring(name,1,3)='abc' --ID nazwy zaczynające się od abc
Wybierz ID z T, gdzie datediff(day,createdate,'2005-11-30')=0--'2005-11-30' generowany id
powinno się zmienić na:
Wybierz ID od T, gdzie nazwa typu 'abc%'
Wybierz ID z T, gdzie utworzono>='2005-11-30' i utworzono<'2005-12-1'
10. Nie wykonuj funkcji, operacji arytmetycznych ani innych operacji wyrażeń po lewej stronie "=" w klauzuli where, w przeciwnym razie system może nie być w stanie poprawnie użyć indeksu.
11. Używając pola indeksu jako warunku, jeśli indeks jest indeksem złożonym, pierwsze pole w indeksie musi być użyte jako warunek zapewniający, że system korzysta z indeksu, w przeciwnym razie indeks nie będzie używany, a kolejność pól powinna być jak najbardziej zgodna z kolejnością indeksu.
12. Nie pisz bezsensownych zapytań, takich jak generowanie pustej struktury tabeli:
Wybierz col1,col2 do #t z T, gdzie 1=0
Ten typ kodu nie zwraca żadnego zestawu wyników, ale zużywa zasoby systemowe, więc powinien zostać zmieniony na coś takiego:
Utwórz tabelę #t(...)
13. Często dobrym wyborem jest zastąpienie w z istnieje:
Wybierz num z A, gdzie num w (wybierz num z b)
Zastąp to następującym stwierdzeniem:
Wybierz num z A gdzie istnieje (wybierz 1 z B, gdzie num = A.num)
14. Nie wszystkie indeksy są ważne dla zapytań, SQL opiera się na danych w tabeli, aby zoptymalizować zapytanie; gdy kolumna indeksu zawiera dużą ilość duplikacji danych, zapytania SQL mogą nie używać indeksu, np. tabela ma płeć pola, męskie, żeńskie to prawie połowa każdy, wtedy nawet jeśli indeks jest zbudowany na podstawie płci, nie będzie on odgrywał roli w efektywności zapytań.
15. Im więcej indeksów, tym lepiej, indeks może z pewnością poprawić efektywność odpowiedniego selekcji, ale także zmniejsza efektywność wstawiania i aktualizacji, ponieważ indeks może być odbudowany podczas wstawiania lub aktualizacji, więc sposób jego budowy wymaga starannego przemyślenia, w zależności od konkretnej sytuacji. Najlepiej nie mieć więcej niż 6 indeksów w tabeli, a jeśli jest ich zbyt wiele, warto rozważyć, czy konieczne jest budowanie indeksów na rzadko używanych kolumnach.
16. Unikaj jak najczęstszej aktualizacji klastrowanych kolumn danych indeksowych, ponieważ kolejność klastrowanych kolumn indeksowych to fizyczna kolejność zapisów tabel, a gdy wartość kolumny się zmieni, dojdzie do zmiany kolejności wszystkich rekordów tabeli, co pochłonie znaczne zasoby. Jeśli twoja aplikacja musi często aktualizować kolumny indeksu klastrowego, musisz rozważyć, czy warto zbudować indeks jako indeks klastrowany.
17. Staraj się używać pól liczbowych i staraj się nie projektować pól zawierających jedynie informacje liczbowe jako znaki, co obniży wydajność zapytań i połączeń oraz zwiększy narzut pamięci. Wynika to z faktu, że silnik porównuje każdy znak w ciągu pojedynczo podczas przetwarzania zapytań i połączeń, podczas gdy dla typów numerycznych wystarczy porównać znaki tylko raz.
18. Używaj varchar/nvarchar zamiast char/nchar tak często, jak to możliwe, ponieważ po pierwsze, dłuższa przestrzeń w polu pozwala zaoszczędzić miejsce, a po drugie, w przypadku zapytań efektywność wyszukiwania w stosunkowo małym polu jest oczywiście wyższa.
19. Nie używaj wybierania * z t, zastąp "*" konkretną listą pól i nie zwracaj pól, które nie są używane.
20. Staraj się używać zmiennych tabelowych zamiast tabel tymczasowych. Jeśli zmienna tabelowa zawiera dużą ilość danych, należy zauważyć, że indeks jest bardzo ograniczony (tylko główny indeks klucza).
21. Unikaj częstego tworzenia i usuwania tabel tymczasowych, aby zmniejszyć zużycie zasobów tabel systemowych.
22. Tabele tymczasowe nie są nieużyteczne, a ich odpowiednie użycie może uczynić niektóre procedury bardziej efektywnymi, na przykład gdy trzeba wielokrotnie odwoływać się do zbioru danych w dużej lub powszechnie używanej tabeli. Jednak w przypadku jednorazowych wydarzeń najlepiej użyć tabeli eksportu.
23. Przy tworzeniu tabeli tymczasowej, jeśli ilość danych wstawionych naraz jest duża, można użyć select into zamiast create table, aby uniknąć powodującego zwiększenie szybkości dużej liczby logów; Jeśli ilość danych nie jest duża, aby zmniejszyć zasoby tabeli systemowej, najpierw utworzyć tabelę, a następnie wstawić.
24. Jeśli używana jest tabela tymczasowa, koniecznie usuń wszystkie tabele tymczasowe na końcu procedury przechowywanej, najpierw ją obcinaj, a następnie usuń tabelę, aby uniknąć długotrwałego zablokowania tabeli systemowej.
25. Staraj się unikać używania kursora, ponieważ jego efektywność jest niska; jeśli dane obsługiwane przez kursor przekraczają 10 000 linii, powinieneś rozważyć przepisywanie kursora.
26. Należy szukać rozwiązań opartych na zbiorach, zanim zacznie stosować metody oparte na kursorze lub tymczasowe metody tabelowe, które często są skuteczniejsze.
27. Podobnie jak tabele tymczasowe, kursory nie są bezużyteczne. Używanie FAST_FORWARD kursorów dla małych zbiorów danych jest często lepsze niż inne metody przetwarzania wiersz po wierszu, zwłaszcza jeśli trzeba odwoływać się do kilku tabel, aby uzyskać potrzebne dane. Procedury zawierające "sumę" w zbiorze wyników są zazwyczaj szybsze niż te wykonywane kursorem. Jeśli czas na rozwój pozwoli, można wypróbować zarówno metody oparte na kursorach, jak i na zbiorach, aby sprawdzić, która działa lepiej.
28. Ustaw USTAW NOCOUNT ON na początku wszystkich procedur i wyzwalaczy, a USTAW NOCOUNT OFF na końcu. Nie ma potrzeby wysyłania DONE_IN_PROC wiadomości do klienta po wykonaniu każdego polecenia procedury przechowywanej i wyzwalania.
29. Starać się unikać dużych operacji transakcyjnych i zwiększać pojemność współbieżności systemu.
30. Staraj się unikać zwracania dużych danych klientowi; jeśli wolumen danych jest zbyt duży, powinieneś rozważyć, czy odpowiadające mu żądanie jest rozsądne. |
Opublikowano 27.01.2015 20:09:54
|
|
|
