Query Tuning Recommendations
Niektóre kwerendy zużywa więcej zasobów niż inne.Na przykład kwerendy zwracającej duży wyniku zestawów i tych, które zawierają WHERE klauzule, które nie są unikatowe są zawsze intensywne zasób.No degree of query optimizer intelligence can eliminate the resource cost of these constructs when compared to a less complex query.SQL Server uses the optimal access plan, but query optimization is limited by what is possible.
Niemniej jednak aby poprawić wydajność kwerendy, można wykonać następujące czynności:
Dodawanie większej ilości pamięci.To rozwiązanie może być szczególnie przydatne, jeśli serwer jest uruchamiany wielu złożonych kwerend i niektóre kwerendy wykonać powoli.
Za pomocą więcej niż jeden procesor.Zezwalaj na wiele procesorów Database Engine Aby za pomocą kwerend równoległych. Aby uzyskać więcej informacji zobaczRównoległego przetwarzania kwerendy.
Od nowa napisać kwerendę.Należy wziąć pod uwagę następujące kwestie:
Jeśli kursorów używanych przez kwerendę, należy określić, jeśli kursor kwerendy można zapisać przy użyciu określonego bardziej wydajne typu kursora (na przykład szybko do przodu — tylko) lub jedną kwerendę.Pojedynczy kwerendy przewyższyć zazwyczaj operacji kursor.Ponieważ zestaw instrukcja kursor jest zazwyczaj operacji pętli zewnętrzne, w którym każdy wiersz w pętli zewnętrzne są przetwarzane po przy użyciu instrukcja SQL wewnętrzne, należy rozważyć przy użyciu instrukcja GROUP BY albo przypadek lub podkwerenda zamiast niego.Aby uzyskać więcej informacji zobacz Cursor Types (Database Engine) i Query Fundamentals.
Jeśli aplikacja używa pętli, należy rozważyć umieszczenie pętli wewnątrz kwerendy.Często aplikacji zawiera pętli, która zawiera sparametryzowana kwerendę, która jest wykonywana wielokrotnie i wymaga sieć zaokrąglone procesu między komputerem, na którym uruchomiona jest aplikacja i SQL Server. Zamiast tego utworzyć pojedynczy, bardziej złożone kwerendy za pomocą tabela tymczasowa.Zaokrąglone procesu pojedynczej sieci jest to konieczne, a optymalizator kwerendy lepiej może zoptymalizować jedną kwerendę.Aby uzyskać więcej informacji zobacz Procedurach języka Transact-SQL i Transact-SQL Variables.
Nie należy używać wiele aliasów dla pojedynczej tabela w tej samej kwerendy do symulacji przecięcia indeksu.Jest to nie konieczności dłużej, ponieważ SQL Server automatycznie traktuje punkt przecięcia się indeksu i można wprowadzać za pomocą wielu indeksów dla tej samej tabela w tej samej kwerendy. Należy wziąć pod uwagę przykładzie kwerendy:
SELECT * FROM lineitem WHERE partkey BETWEEN 17000 AND 17100 AND shipdate BETWEEN '1/1/1994' AND '1/31/1994'SQL Server można wykorzystać indeksów w obu partkey and shipdate kolumn, a następnie wykonaj mieszania zgodność dwóch podzestawy uzyskanie przecięcia indeksu.
Aby zezwolić na ponowne użycie pamięci podręcznej kwerendy planów wykonania za pomocą parametryzacji kwerendy.Jeśli zestaw kwerendy ma ten sam mieszania kwerendy i mieszania planu kwerendy, może zwiększyć wydajność, tworząc jeden kwerendy parametryczne.Wywołanie jednej kwerendy z parametrami zamiast wielu kwerend z wartości literałów umożliwia ponowne użycie plan wykonania kwerend pamięci podręcznej.Aby uzyskać więcej informacji zobacz Finding and Tuning Similar Queries by Using Query and Query Plan Hashes i Wykonanie planu buforowanie i ponowne użycie.
Jeśli aplikacja nie może modyfikować, umożliwia szablonu planu prowadnice z wymuszone parametryzacji uzyskać podobny efekt.Aby uzyskać więcej informacji zobaczSpecifying Query Parameterization Behavior by Using Plan Guides.
Należy używać wskazówek kwerendy tylko wtedy, gdy jest to konieczne.Kwerendy zawierające instrukcję wskazówki wykonywane przed we wcześniejszych wersjach SQL Server należy przetestować bez wskazówki, określona. Wskazówki mogą uniemożliwić wybranie lepszego planu wykonywania optymalizator kwerendy.Aby uzyskać więcej informacji zobaczSELECT (Transact-SQL).
The query_plan_hash służy do przechwytywania, przechowywać i porównać planów wykonanie kwerendy dla kwerendy w czasie.Na przykład po zmianie konfiguracja systemu, można porównać wartości mieszania planu kwerendy dla misji krytycznych kwerendy w celu przywrócenia oryginalnych wartości mieszania planu kwerendy.Różnice wartości mieszania planu kwerendy powinien powiedzieć, którego zmiany konfiguracja systemu spowodowało planów wykonywanie kwerend zaktualizowane dla kwerend ważne.Można również zdecydować zatrzymać wykonywanie dla bieżącego długo działającą kwerendę, jeśli jego wartość mieszania planu kwerendy w sys.dm_exec_requests różni się od jego mieszania planu kwerendy według planu bazowego, który jest dobrą wydajnością.Aby uzyskać więcej informacji zobaczFinding and Tuning Similar Queries by Using Query and Query Plan Hashes.
Należy korzystać z zarządca zapytań opcji konfiguracja.The zarządca zapytań konfiguracja option can be used to prevent system resources from being consumed by long-running queries.Domyślnie opcja ta zestaw aby zezwolić na wszystkie kwerendy do wykonać, niezależnie od tego, jak długo podjęte.Można jednak ustawić zarządca zapytań, aby ograniczyć maksymalną liczbę sekund, które można wykonać dla wszystkich połączeń lub po prostu kwerendy dla określonego połączenia wszystkie kwerendy.Ponieważ zarządca zapytań jest oparta na kwerendy szacowany koszt, a nie rzeczywisty czas, nie ma żadnych wykonywania dodatkowe obciążenie.Zatrzymuje również kwerendach o długim przed ich uruchomieniem zamiast uruchamiania ich naciśnięciu niektórych wstępnie zdefiniowany limit.Aby uzyskać więcej informacji zobacz query governor cost limit Option i SET QUERY_GOVERNOR_COST_LIMIT (Transact-SQL).
Optymalizacja ponownego użycia planów kwerend z pamięci podręcznej planu.The Database Engine caches query plans for possible reuse.Jeżeli plan kwerend nie są buforowane, to może nigdy nie być ponownie użyte.Zamiast tego planów kwerend niezbuforowane musi zostać skompilowany przy każdym wykonywane są przydzielane w sposób wpływa na zmniejszenie wydajności.Poniżej Transact-SQL Opcji instrukcja zestaw uniemożliwić ich ponownego użycia planów kwerend pamięci podręcznej. A Transact-SQL wsadowy, zawierający te opcje zestaw ON włączony nie można udostępnić swoje plany kwerend z tej samej instancji, która została skompilowana z tych opcji zestaw wyłączone:
ZESTAW ANSI_NULL_DFLT_OFF
ZESTAW ANSI_NULL_DFLT_ON
ZESTAW ANSI_NULLS
ZESTAW ANSI_PADDING
ZESTAW ANSI_WARNINGS
ZESTAW ARITHABORT
zestaw CONCAT_NULL_YIELDS_NULL
zestaw DATEFIRST
zestaw DATEFORMAT
ZESTAW FORCEPLAN
zestaw JĘZYKA
ZESTAW NO_BROWSETABLE
ZESTAW NUMERIC_ROUNDABORT
zestaw QUOTED_IDENTIFIER
ZESTAW TEXTSIZE
Ponadto opcja zestaw ANSI_DEFAULTS wpływają na ponownego użycia planów kwerendy buforowana, ponieważ może służyć do zmiany ANSI_NULLS, ANSI_NULL_DFLT_ON, ANSI_PADDING, ANSI_WARNINGS, CURSOR_CLOSE_ON_COMMIT, IMPLICIT_TRANSACTIONS i opcji QUOTED_IDENTIFIER zestaw.Należy zauważyć, że większość opcji zestaw, które mogą być zmieniane z zestaw ANSI_DEFAULTS są wyświetlane jako opcje zestaw, które mogą mieć wpływ na ich ponownego użycia planów kwerend.
Można zmienić niektóre z tych opcji zestaw z następujących metod:
Użycie sp_configure przechowywane procedury zmian na poziomie serwera.Aby uzyskać więcej informacji zobaczsp_configure (języka Transact-SQL).
Za pomocą klauzula zestaw instrukcja ALTER DATABASE.Aby uzyskać więcej informacji, zobacz ALTER DATABASE języka Transact-SQL)
Zmienianie ustawień połączenia OLE DB i ODBC.Aby uzyskać więcej informacji zobaczClient Network Configuration.
Uwaga
Aby uniknąć ponowne kompilacje spowodowane opcji zestaw planów kwerendy, ustanowienie opcji zestaw w czasie połączenia i upewnij się, że nie należy ich zmieniać na czas trwania połączenia.Niektóre opcje zestaw musi należeć do określonej wartości do korzystania z widoków indeksowanych lub indeksy w kolumny obliczane.Aby uzyskać więcej informacji zobaczSET Options That Affect Results.