Słyszałem o statystykach, które domyślnie przechowuje SQL Server. Co one śledzą i jak mogę wykorzystać te informacje do ulepszenia mojej bazy danych?
Statystyki są po prostu formą dynamicznych metadanych, które pomagają optymalizatorowi zapytań w podejmowaniu lepszych decyzji. Na przykład, jeśli w tabeli jest tylko tuzin wierszy, nie ma sensu chodzić do indeksu, aby wyszukać; zawsze lepiej będzie wykonać pełne skanowanie tabeli. Ale jeśli ta sama tabela wzrośnie do miliona wierszy, prawdopodobnie lepiej będzie skorzystać z indeksu. Ale jeśli zapytasz tę tabelę o kolumnę, która ma tylko bardzo niewiele unikalnych wartości (np. Może to być kolumna „płeć” zawierająca tylko „M” lub „F”), tak naprawdę FTS może być lepszy od tego przypadku, ponieważ i tak trzeba pobrać blok, aby zbudować zestaw wyników. Powiedzmy teraz, że twoja tabela ma 99% „M” i tylko 1% „F”, powinniśmy FTS w jednym przypadku lub użyć indeksu w drugim. Ta sama tabela, to samo zapytanie, potencjalnie cztery różne plany zapytań w zależności od zawartości tabeli. Tego rodzaju rzeczy są „statystykami” i są indywidualne dla każdej bazy danych - nawet dwie bazy danych o identycznej strukturze tabeli i indeksu będą miały różne statystyki.
Podsumowując, w nowoczesnym silniku bazy danych istnieją dwa rodzaje optymalizacji zapytań: przepisywanie kodu SQL (optymalizacja oparta na regułach, podobnie jak kompilator przepisuje C, aby uczynić go bardziej wydajnym) i wybór właściwej ścieżki danych (optymalizacja oparta na kosztach , jak kompilator JIT identyfikujący punkty aktywne w czasie wykonywania). Musisz się tym martwić tylko wtedy, gdy zauważysz, że optymalizator zapytań robi coś oczywiście złego (np. Wybranie FTS, gdy wiesz, że indeks byłby lepszy).
Są one używane przez optymalizator zapytań (oficjalny dokument na MSDN) do śledzenia rozkładu wartości w indeksach i / lub kolumnach.
Twoim jedynym zmartwieniem powinna być regularna aktualizacja : po prostu zostaw silnik DB, aby zrobić swoje
źródło