Det är sant att det går snabbare att modifiera en tabell om man inte också måste modifiera ett eller flera index och eventuellt utföra begränsningskontroll också, men det är också i stort sett irrelevant om man sedan måste lägga till dessa index. Du måste överväga den fullständiga förändringen av systemet som du vill genomföra, inte bara en del av det.
Om du lägger till en enstaka rad i en tabell som redan innehåller miljontals rader skulle det naturligtvis vara dumt att släppa och bygga om index.
Men även om du har en helt tom tabell där du ska lägga till flera miljoner rader kan det fortfarande gå långsammare att skjuta upp indexeringen till efteråt.
Anledningen till detta är att en sådan infogning bäst utförs med den direkta sökvägsmekanismen, och när du använder direkta sökvägsinfogningar i en tabell med index på byggs temporära segment som innehåller de data som krävs för att bygga indexen (data plus rader). ). Om de temporära segmenten är mycket mindre än tabellen du just har laddat kommer de också att vara snabbare att skanna och bygga index från.
alternativet, om du har fem index på bordet, är att göra fem hela tabellskanningar efter att du har laddat det för att bygga indexen.
Uppenbarligen är det enorma gråzoner inblandade här, men bra gjort för:
- Frågande auktoritet och allmänna tumregler, och
- Köra faktiska tester för att fastställa fakta i ditt eget fall.
Redigera:
Ytterligare överväganden -- du kör en säkerhetskopia medan indexen släpps. Nu, efter en nödåterställning, måste du ha ett skript som verifierar att alla index är på plats, när du får företaget att andas ner dig för att få upp systemet igen.
Dessutom, om du absolut var fast besluten att inte behålla index under en bulkbelastning, släpp inte indexen - inaktivera dem istället. Detta bevarar metadata för indexens existens och definition, och möjliggör en enklare ombyggnadsprocess. Var bara försiktig så att du inte av misstag återaktiverar index genom att trunkera tabellen, eftersom detta kommer att göra inaktiverade index aktiverade igen.