2013-05-21 41 views
7

W Teradata mogę użyć instrukcji jak ...Korzystanie gromadzenia statystyk w Teradata

collect statistics on my_table column(col1) 

ten zbierze statystyk na stole i przechowywać je w widokach DBC jak ColumnStats, IndexStats i MultiColumnStats. Mam też wrażenie, że optymalizator (silnik analizowania) znajdzie statystyki, gdy będą dostępne, i użyje ich zamiast szacowanej liczności tabeli/wartości indeksu, aby lepiej podejmować decyzje dotyczące wykonywania zapytania.

Wszystko brzmi świetnie, ale mam kilka pytań.

  • Czy są jakieś wady korzystania z collect stats?
  • Kiedy jest właściwe/niewłaściwe używanie zbierania statystyk w skryptach SQL?
  • Jakie są korzyści związane z wydajnością zbierania statystyk na polu, które jest już zindeksowane?
  • Jak długo przechowywane są statystyki (tabela, tabele ulotne)?
  • Wszelkie inne uwagi dotyczące collect statistics będą mile widziane.
+0

Niestety ale IMO to pytanie nie jest „dobre dopasowanie” dla SO. Gromadzenie statystyk jest bardzo ważną, być może istotną częścią Teradata i istnieje wiele artykułów online, które omawiają ten temat. Ponadto, masz zbyt wiele różnych części do tego pytania, aby uzyskać wyraźną odpowiedź. Każda z kul może być warta ponownego pytania. Głosowanie na zakończenie jako "nie konstruktywne". – BellevueBob

+0

Hej, Bob, czy uważasz, że byłoby lepiej przystosować go do migracji pytania do strony Database Administrator SO, zamiast głosowania na "nie konstruktywne"? Znalazłem artykuły, ale nikt tak naprawdę nie odpowiada na moje pytania – ChrisCamp

Odpowiedz

10

1> czy są jakieś wady korzystania zbierania statystyk?

Tak, zbieranie statystyk sam jest czasochłonne, to faktycznie zlokalizować dane z AMPS i wstawić statystyk w tabelach słownikowych.

Załóżmy, że masz definicję tabeli, takich jak:

ct T1 (int x1, int y1, z1 int);

tabela zawiera miliony wierszy i Z1 nie jest stosowana w warunkach ST/join, to nie warto zbierać statystyki na z1.

2> Kiedy jest właściwe/niewłaściwe korzystanie z gromadzenia statystyk w skryptach SQL?

Już odpowiedziałeś powyżej. Jeśli kolumna będzie używana jako warunek ST/Join .i.e w klauzuli where lub on, musisz zebrać statystyki, w przeciwnym razie nie będzie to konieczne.

3> Jakie korzyści wydajności do zbierania danych statystycznych na polu, które już indeksowane?

CT T1 (Int x1, y1 int) wskaźnik pierwotnego (X1);

dla prostego zapytania, takiego jak sel * od t1, gdzie x1 = 5;

zademonstruje przydatność statystyk zbierania.

Jak?

optymalizator może prawidłowo oszacować ile wierszy ta kwerenda będzie wybrać i jeśli t1 będzie połączone z powiedzieć, T2, to wydajny dołączyć zostanie wybrany przez optymalizator.

4> Jak długo przechowywane są statystyki (tabela, tabele ulotne)?

Tabela: na stałe.

Tabele zmienne: sesja wygasa.

5> Wszelkie inne uwagi dotyczące statystyki zbierania będą mile widziane.

Nic nie zostało omówione na temat statystyk wielokolumn.

znaczy, że zapytanie jest podobnym

SEL * od t1 przyłączenia t2 Y1 = Y2 i X1 = 2;

następnie zbieranie statystyk wielu kolumn na (x1, y1) byłoby bardzo pomocne w optymalizacji.

Ponadto, jeśli tabela demografia została zmieniona (zwiększenie liczby wierszy), należy rozważyć ponowne zbieranie statystyk

+0

Hej, tu, doceniam przemyślaną odpowiedź – ChrisCamp