sql >> Databáze >  >> RDS >> Oracle

Shromáždit statistiky o indexu nebo vytvořit pokles?

Rozdíl je v tom, že shromažďování statistik obnovuje metadata o aktuálním indexu, zatímco vypuštění a opětovné vytvoření indexu znamená vypuštění a opětovné vytvoření indexu.

Snad je snadné pochopit rozdíl na zpracovaném příkladu. Vytvořme tedy tabulku a index:

SQL> create table t23 
  2  as select object_id as id, object_name as name from user_objects 
  3  /

Table created.

SQL> create index i23 on t23(id)
  2  /

Index created.

SQL> select o.object_id, i.last_analyzed, i.distinct_keys
  2  from user_objects o
  3       join user_indexes i
  4            on (i.index_name = o.object_name)
  5  where o.object_type = 'INDEX'
  6  and i.index_name = 'I23'
  7  /

 OBJECT_ID CREATED              LAST_ANALYZED        DISTINCT_KEYS
---------- -------------------- -------------------- -------------
    116353 23-NOV-2013 00:15:39 23-NOV-2013 00:15:39           167

1 row selected.

SQL> 

Od 11g Oracle automaticky shromažďuje statistiky, když vytváříme index. Takže vytvoření indexu a poslední analýza ukazují stejné datum a čas. V předchozích verzích jsme museli explicitně shromažďovat statistiky poté, co jsme vytvořili index. Další informace .

Dále přidáme nějaká data a obnovíme statistiky:

SQL> insert into t23 values (9999, 'TEST1')
  2  /

1 row created.

SQL> insert into t23 values (-8888, 'TEST 2')
  2  /

1 row created.

SQL> exec dbms_stats.gather_index_stats(user, 'I23') 

PL/SQL procedure successfully completed.

SQL> select o.object_id, i.last_analyzed, i.distinct_keys
  2  from user_objects o
  3       join user_indexes i
  4            on (i.index_name = o.object_name)
  5  where o.object_type = 'INDEX'
  6  and i.index_name = 'I23'
  7  /

 OBJECT_ID CREATED              LAST_ANALYZED        DISTINCT_KEYS
---------- -------------------- -------------------- -------------
    116353 23-NOV-2013 00:15:39 23-NOV-2013 00:26:28           169

1 row selected.

SQL> 

Nyní se metadata týkající se statistik změnila, ale index je stejný databázový objekt. Zatímco pokud index zrušíme a znovu vytvoříme, získáme nový databázový objekt:

SQL> drop index i23
  2  /

Index dropped.

SQL> create index i23 on t23(id) 
  2  /

Index created.

SQL> select o.object_id, i.last_analyzed, i.distinct_keys
  2  from user_objects o
  3       join user_indexes i
  4            on (i.index_name = o.object_name)
  5  where o.object_type = 'INDEX'
  6  and i.index_name = 'I23'
  7  /

 OBJECT_ID CREATED              LAST_ANALYZED        DISTINCT_KEYS
---------- -------------------- -------------------- -------------
    116354 23-NOV-2013 00:27:50 23-NOV-2013 00:27:50           169

1 row selected.

SQL> 

V běžném provozu téměř nikdy nepotřebujeme index vypustit a znovu vytvořit. Je to technika, která je někdy vhodná při načítání velkého množství dat a ve velmi vzácných případech poškození indexu. Interweby stále vyhazují stránky, které doporučují pravidelné přestavování indexů z důvodu výkonu (údajně to „vyrovnává“ zkreslené indexy), ale tyto stránky nevytvářejí benchmarky, které by prokázaly dlouhodobé přínosy, a rozhodně nikdy nezahrnují čas a Cykly CPU promarněné cvičením přestavby.

Opětovné sestavení indexu vyžaduje více práce než obnovování statistik. Očividně pravda, protože přestavba zahrnuje sběr statistik jako dílčí úkol. Otázkou je, zda je efektivnější provádět hromadné DML proti tabulce se svými indexy na místě ve srovnání s vypuštěním indexů a následným opětovným vytvořením. Může být rychlejší načíst data do tabulky bez indexů a poté je znovu vytvořit.

Neexistuje zde žádné pevné a rychlé pravidlo:záleží na tom, kolik máte indexů, na poměru ovlivněných řádků k celé velikosti tabulky, zda potřebujete indexy k vynucení omezení relační integrity a tak dále. Mezi operacemi je také velký rozdíl:možná budete chtít zrušit indexy pro hromadné vkládání, ale zachovat je pro aktualizace, v závislosti na tom, jaké indexy potřebujete pro klauzuli WHERE a zda aktualizace ovlivní indexované sloupce.

Stručně řečeno, musíte porovnat svůj vlastní konkrétní scénář. To je často odpověď na otázky týkající se výkonu.




  1. mysql_fetch_assoc():zadaný argument není platným zdrojem výsledků MySQL v php

  2. Zprovoznění MySQL na OSX 10.7 Lion

  3. Vyhledejte řetězec podle přesného slova v Mysql

  4. Jak potopit téma kafka do orákula pomocí kafka connect?