Czy SQL źle wpływa na wydajność?

Jeśli masz dobry indeks na FieldW, użycie tego w jest całkowicie właściwe.

Właśnie przetestowałem i SQL 2000 robi skan indeksu klastrowego podczas korzystania z IN.

Możesz spróbować utworzyć tabelę tymczasową, wstawić do niej swoje wartości i użyć tabeli w predykacie IN.

AFAIK, SQL Server 2000 nie może zbudować tabeli hash zbioru stałych, co pozbawia optymalizatora możliwości użycia HASH SEMI JOIN.

To pomoże tylko jeśli nie masz indeksu na FieldW (który powinieneś mieć).

Możesz również spróbować dołączyć swoje kolumny FieldX i FieldY do indeksu:

CREATE INDEX ix_a_wxy ON a (FieldW, FieldX, FieldY)

Tak aby zapytanie mogło być obsłużone tylko za pomocą indeksu.

SQL Server 2000 Brak opcji INCLUDE dla CREATE INDEX i może to nieco obniżyć wydajność DML, ale poprawić wydajność zapytań.

Update:

Z twojego planu wykonania widzę, że potrzebujesz indeks złożony na (SettingsID, SectionID)

SQL Server 2000 rzeczywiście może zbudować tabelę hashową ze stałej listy( i robi to), ale Hash Semi Join najprawdopodobniej będzie mniej wydajna niż Nested Loop dla zapytań.

I jeszcze jedna uwaga: jeśli musisz znać liczba wierszy spełniających warunek WHERE, nie używaj COUNT(column), zamiast tego użyj COUNT(*).

A COUNT(column) nie liczy wierszy, dla których wartością column jest NULL.

Oznacza to, że po pierwsze, możesz uzyskać wyniki, których się nie spodziewałeś, a po drugie, optymalizator będzie musiał zrobić dodatkowe Key Lookup / Bookmark Lookup jeśli twoja kolumna nie jest objęta indeksem spełniającym warunek WHERE.

Ponieważ ThreadId wydaje się być CLUSTERED PRIMARY KEY, jest w porządku dla tego samego zapytania, ale staraj się go unikać ogólnie.

W zależności od dystrybucji danych, dodatkowe predykaty w klauzuli WHERE mogą poprawić wydajność. Na przykład, jeśli zestaw identyfikatorów jest mały w stosunku do całkowitej liczby w tabeli i wiesz, że identyfikatory są stosunkowo blisko siebie (być może będą to zwykle Ostatnie dodatki, a zatem klastry na najwyższym końcu zakresu), możesz spróbować dołączyć predykat "i FieldW między 109 A 891" (po określeniu id min & max w twoim zestawie w kodzie C#). Informatyka może być tak, że skanowanie zakresu tych kolumn (jeśli jest indeksowane) działa szybciej niż obecnie używane.

Są lepsze sposoby, aby to zakodować, ale wątpię, że to jest przyczyna twoich przerw czasowych, zwłaszcza jeśli jest to tylko SELECT. Powinieneś być w stanie to określić, patrząc na ślady zapytań. Ale przekodowanie tego byłoby optymalizacją przez zgadywanie, i mało prawdopodobne przypuszczenie na to.

Zacznijmy od planu zapytań dla zapytania, które jest faktycznie timing out. Czy wiesz na pewno, które to zapytanie?

IN to dokładnie to samo, co pisanie dużej listy RNO. Lub często sprawia, że zapytania nie są kierowane, więc indeksy mogą być ignorowane, a plan obejmuje pełne skanowanie.

Zazwyczaj klauzula IN jest szkodliwa dla wydajności, ale to, co jest "złe", zależy od aplikacji, danych, wielkości bazy danych itp. Musisz przetestować własną aplikację, aby zobaczyć, co jest najlepsze.

Zasadniczo to, co robi klauzula where, TO " FieldW = 108 lub FieldW = 109 lub FieldW = 113...". Czasami można uzyskać lepszą wydajność, wykonując wiele wyborów i łącząc je z union. Na przykład:

SELECT FieldX, FieldY FROM A WHERE FieldW = 108
UNION ALL
SELECT FieldX, FieldY FROM A WHERE FieldW = 109

Inną opcją może być wstawienie tych wartości do tabeli tymczasowej, a następnie dołączenie tabeli A do tej tabeli tymczasowej.

Rozmiar tabeli określi prędkość podczas korzystania z tej instrukcji. Jeśli to nie jest zbyt duży stół...to stwierdzenie nie wpływa na Twoje wyniki.

Oto Twoja odpowiedź...

Http://www.4guysfromrolla.com/webtech/031004-1.shtml

Zasadniczo chcesz utworzyć funkcję, która podzieli łańcuch znaków i wypełni tabelę tymczasową podzieloną zawartością. Następnie możesz dołączyć do tej tabeli tymczasowej i manipulować danymi. Powyższe wyjaśnia rzeczy całkiem dobrze. Często używam tej techniki.

W twoim konkretnym przypadku użyj join do tabeli temp zamiast klauzuli in, znacznie szybciej.

Ogólnie używałbym zdefiniowanego przez użytkownika typu tabeli dla takich zapytań.

CREATE TYPE [dbo].[udt_int] AS TABLE (
    [id] [int] NOT NULL
)

Używając zmiennej tabel i wypełniając ją wierszami dla każdej z liczb, możesz zrobić:

SELECT 
    FieldX, 
    FieldY
FROM A
INNER JOIN @myIds B ON
    A.FieldW = B.id

Wydajność może być oceniana tylko w kontekście tego, co próbujesz zrobić. W tym przypadku żądasz odzyskania około 70 wierszy (zakładając, że są to unikalne wartości), więc możesz spodziewać się czegoś w rodzaju 70 razy czasu pobierania pojedynczej wartości. Może być mniej z powodu buforowania lub kursu.

Jednak optymalizator zapytań może potrzebować lub wybrać pełne skanowanie tabeli w celu pobrania wartości, w którym to przypadku performace będzie niewiele różnił się od pobierania jedną wartość za pośrednictwem tego samego planu dostępu.

Jeśli możesz użyć innych rzeczy niż w: zrób to (używałem w w niektórych przypadkach nie bardzo dobry sposób : mogę łatwo zastąpić exist i jest szybciej)

W Twoim przypadku: nie wydaje się tak źle.

Możesz spróbować czegoś takiego:

select a.FieldX, a.FieldY
from (
    select FieldW = 108 union
    select FieldW = 109 union
    select FieldW = 113 union
    ...
    select FieldW = 891
) _a
join A a on a.FieldW = _a.FieldW

Może to być odpowiednie dla twojej sytuacji, na przykład gdy chcesz dynamicznie wygenerować pojedyncze polecenie SQL. Na moim komputerze (SQL Server 2008 Express), testowanie z małą liczbą (5) wartości FieldW i dużą liczbą (100,000) wierszy W A, używa wyszukiwania indeksu na a z zagnieżdżoną pętlą łączącą się między A i _a, co prawdopodobnie jest tym, czego szukasz.