Serwer SQL: wydajność danych szeregów czasowych

Question

Mam tabelę z nieco ponad 1 miliardem wierszy danych z serii czasowej z fantastyczną wydajnością wstawiania, ale (czasami) strasznie wybraną wydajnością.

Tabela tblTrendDetails (PK zamówić, jak pokazano)

PK TrendTime datetime 
PK CavityId  int 
PK TrendValueId int 
    TrendValue real 

Tabela stale wciągania nowych danych i oczyszczanie starych danych, a więc wprowadzać i usuwać wyniki powinny pozostawać żwawy.

Podczas wykonywania dalszych takich jak następujących, wydajność jest niska (30 s)

SELECT * 
FROM tblTrendDetails 
WHERE TrendTime BETWEEN @inMinTime AND @inMaxTime 
    AND CavityId = @inCavityId 
    AND TrendValueId = @inTrendId 

Jeśli ponowne uruchomienie samego zapytania (z podobnym czasie, ale każdy @inCavityId lub @inTrendId) wydajność jest bardzo dobry (1 s). Liczniki wydajności pokazują, że dostęp do dysku jest sprawcą przy pierwszym uruchomieniu zapytania.

Wszelkie zalecenia dotyczące poprawy wydajności bez (znaczącego) niekorzystnego wpływu na wydajność wstawiania lub usuwania? Wszelkie sugestie (w tym całkowita zmiana bazy danych) są mile widziane.

Answer 1

Fakt, że kolejne zapytania o te same lub podobne dane działają znacznie szybciej, wynika prawdopodobnie z SQL Server caching your data. To powiedziawszy, czy możliwe jest przyspieszenie początkowych zapytań?

Weryfikacja planu kwerend:

Domyślam się, że zapytanie powinno skutkować w indeksie Szukajcie raczej niż skanowanie indeksu (lub, co gorsza, skanowanie tabeli). Sprawdź to za pomocą SET SHOWPLAN_TEXT ON; lub podobnej funkcji. Używanie between i = jako zapytania naprawdę powinno być take advantage of the clustered index, chociaż that's debatable.

Rozdrobnienie Index:

Jest możliwe, że indeks klastra (klucz podstawowy w tym przypadku) jest dość rozdrobniony po wszystkich tych wkładek i usuwa. Prawdopodobnie sprawdziłbym to z DBCC SHOWCONTIG (tblTrendDetails).

Możesz defragmentować indeksy tabeli za pomocą DBCC INDEXDEFRAG (MyDatabase, tblTrendDetails). Może to zająć trochę czasu, ale pozwoli, aby tabela pozostała dostępna, i możesz zatrzymać operację bez żadnych nieprzyjemnych efektów ubocznych.

Być może będziesz musiał pójść dalej i użyć DBCC DBREINDEX (tblTrendDetails). Jest to jednak operacja w trybie offline, więc powinieneś to zrobić tylko wtedy, gdy nie ma potrzeby otwierania tabeli.

Istnieje kilka opisanych tutaj różnic: Microsoft SQL Server 2000 Index Defragmentation Best Practices.

Należy pamiętać, że dziennik transakcji może znacznie wzrosnąć po defragnieniu dużej tabeli i może to zająć dużo czasu.

PARTITIONED Odwiedzin:

Jeśli te nie poprawy sytuacji (lub fragmentacja nie stanowi problemu), może nawet chcą patrzeć partitioned views, w którym można tworzyć kilka podstawowych tabel bazowych dla różnych zakresy rekordów, a następnie połącz je wszystkie w widoku (zastępując oryginalną tabelę).

Lepsze rzeczy:

Jeśli wydajność tych wybiera to prawdziwy biznes potrzeba, może być w stanie dokonać sprawę do lepszego sprzętu: Szybsze dyski, więcej pamięci, itd. Jeśli dyski są dwukrotnie szybko, to zapytanie będzie działało w połowie czasu, tak? Ponadto może to nie być możliwe, ale po prostu znalazłem nowsze wersje SQL Server, aby naprawdę być szybszym z większą ilością opcji i lepszym do utrzymania. Cieszę się, że większość danych mojej firmy przeniosłem do 2008R2. Ale dygresja ...