Skillnaden är att insamling av statistik uppdaterar metadata om det aktuella indexet medan att släppa och återskapa indexet är, eh, att släppa och återskapa indexet.
Kanske är det lätt att förstå skillnaden med ett bearbetat exempel. Så låt oss skapa en tabell och ett 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>
Eftersom 11g Oracle automatiskt samlar in statistik när vi skapar ett index. Så indexskapande och senaste analys visar samma datum och tid. I tidigare versioner var vi tvungna att explicit samla in statistik efter att vi skapat indexet. Läs mer .
Därefter lägger vi till lite data och uppdaterar statistiken:
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>
Nu har metadata för statistik ändrats men indexet är samma databasobjekt. Om vi släpper och återskapar indexet får vi ett nytt databasobjekt:
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>
I normal verksamhet behöver vi nästan aldrig släppa och återskapa ett index. Det är en teknik som ibland är lämplig när man laddar mycket stora mängder data och i mycket sällsynta fall av indexkorruption. Interwebs slänger fortfarande upp sajter som rekommenderar regelbunden ombyggnad av index av prestationsskäl (det påstås "ombalansera" snedställda index) men dessa sajter producerar inte riktmärkena för att bevisa de långsiktiga fördelarna, och inkluderar definitivt aldrig tid och CPU-cykler slösas bort av återuppbyggnadsövningen.
Att bygga om ett index kräver mer arbete än att uppdatera statistiken. Uppenbarligen sant, eftersom ombyggnad inkluderar insamling av statistik som en deluppgift. Frågan är om det är mer effektivt att genomföra bulk-DML mot en tabell med dess index på plats jämfört med att ta bort indexen och återskapa efteråt. Det kan gå snabbare att ladda in data i en tabell utan index och återskapa dem i efterhand.
Det finns ingen hård-och-snabb regel här:det beror på hur många index du har, andelen rader som påverkas mot hela tabellens storlek, om du behöver indexen för att upprätthålla relationella integritetsbegränsningar, och så vidare. Det finns också en stor skillnad mellan operationer:du kanske vill ta bort index för bulkinfogningar men behålla dem för uppdateringar, beroende på vilka index du behöver för din WHERE-sats och om uppdateringen påverkar indexerade kolumner.
Kort sagt, du måste jämföra ditt eget specifika scenario. Detta är ofta svaret när det kommer till prestationsfrågor.