Index skapas på tabell- och vykolumner. Index ger ett sätt att snabbt söka data baserat på värdena i dessa kolumner. Om du till exempel skapar ett index på en primärnyckel och sedan söker efter en rad med data med hjälp av primärnyckelvärdena, SQL Server hittar först indexvärdet och använder sedan indexet för att snabbt hitta hela raden med data. Utan ett index kommer en fullständig genomsökning av alla rader i tabellen att utföras, vilket kan ha en betydande inverkan på prestanda.
Du kan skapa ett index för de flesta kolumner i en tabell eller vy. Undantaget är främst kolumner med datatyper för lagring av stora objekt ( LOBB), Till exempel bild, text eller varchar(max). Du kan också skapa index på kolumner som är utformade för att lagra data i formatet XML, men dessa index är strukturerade något annorlunda än standardindexen och deras övervägande ligger utanför ramen för denna artikel. Dessutom diskuterar inte artikeln kolumnbutik index. Istället fokuserar jag på de index som är vanligast i databaser SQL Server.
Ett index består av en uppsättning sidor, indexnoder, som är organiserade i en trädstruktur - balanserat träd. Denna struktur är hierarkisk till sin natur och börjar med en rotnod överst i hierarkin och lövnoderna, bladen, längst ner, som visas i figuren:


När du frågar en indexerad kolumn startar frågemotorn överst i rotnoden och arbetar sig ner genom de mellanliggande noderna, där varje mellanlager innehåller mer detaljerad information om data. Frågemotorn fortsätter att röra sig genom indexnoderna tills den når bottennivån med indexbladen. Till exempel, om du letar efter värdet 123 i en indexerad kolumn, kommer frågemotorn först att fastställa sidan på den första mellannivån på rotnivån. I det här fallet pekar den första sidan på ett värde från 1 till 100 och den andra från 101 till 200, så sökmotorn kommer åt den andra sidan på denna mellannivå. Därefter kommer du att se att du bör gå till den tredje sidan på nästa mellannivå. Härifrån kommer frågeundersystemet att läsa värdet på själva indexet på en lägre nivå. Indexblad kan innehålla antingen själva tabelldatan eller helt enkelt en pekare till rader med data i tabellen, beroende på typen av index: klustrat index eller icke-klustrat index.

Klustrat index

Icke-klustrade index

Typer av index

Sammansatt index

Unikt index

• Primärnyckel
  När du definierar en primärnyckelrestriktion på en eller flera kolumner då SQL Server skapar automatiskt ett unikt klustrat index om ett klustrat index inte har skapats tidigare (i det här fallet skapas ett unikt icke-klustrat index på primärnyckeln)
• Värderingars unika
  När du definierar en begränsning för unika värden då SQL Server skapar automatiskt ett unikt icke-klustrat index. Du kan ange att ett unikt klustrat index ska skapas om inget klustrat index ännu har skapats i tabellen

Täckande index

Designa index

Databas

• För tabeller som uppdateras ofta, använd så få index som möjligt.
• Om tabellen innehåller en stor mängd data men ändringarna är små, använd så många index som behövs för att förbättra prestandan för dina frågor. Tänk dock noga efter innan du använder index på små tabeller, eftersom... Det är möjligt att det kan ta längre tid att använda en indexsökning än att bara skanna alla rader.
• För klustrade index, försök att hålla fälten så korta som möjligt. Det bästa tillvägagångssättet är att använda ett klustrat index på kolumner som har unika värden och inte tillåter NULL. Det är därför en primärnyckel ofta används som ett klustrat index.
• Det unika hos värdena i en kolumn påverkar indexets prestanda. Generellt gäller att ju fler dubbletter du har i en kolumn, desto sämre presterar indexet. Å andra sidan, ju mer unika värden det finns, desto bättre prestanda för indexet. Använd ett unikt index när det är möjligt.
• För ett sammansatt index, ta hänsyn till ordningen på kolumnerna i indexet. Kolumner som används i uttryck VAR(Till exempel, WHERE FirstName = "Charlie") måste vara först i indexet. Efterföljande kolumner bör listas baserat på unikheten hos deras värden (kolumner med det högsta antalet unika värden kommer först).
• Du kan också ange ett index på beräknade kolumner om de uppfyller vissa krav. Till exempel måste uttryck som används för att erhålla värdet på en kolumn vara deterministiska (lämna alltid samma resultat för en given uppsättning indataparametrar).

Databasfrågor

• Försök att infoga eller ändra så många rader som möjligt i en fråga, istället för att göra det i flera enskilda frågor.
• Skapa ett icke-klustrat index på kolumner som ofta används som söktermer i dina frågor. VAR och anslutningar i ANSLUTA SIG.
• Överväg att indexera kolumner som används i raduppslagsfrågor för exakta värdematchningar.

Och nu faktiskt:

14 frågor om index i SQL Server som du skämdes över att ställa

Varför kan en tabell inte ha två klustrade index?

Om en klustrad tabell ger många fördelar, varför använda en hög då?

Hur ändrar jag standardindexfyllningsfaktorn?

Är det möjligt att skapa ett klustrat index på en kolumn som innehåller dubbletter?

Hur lagras tabellen om ett klustrat index inte har skapats?

Vilket är förhållandet mellan begränsningar för värdeunikt och en primärnyckel med tabellindex?

Varför kallas klustrade och icke-klustrade index B-tree i SQL Server?

Hur kan ett index till och med förbättra frågeprestanda om du måste gå igenom alla dessa indexnoder?

Om index är så bra, varför inte bara skapa ett på varje kolumn?

Är det nödvändigt att skapa ett klustrat index på en kolumn med en primärnyckel?

Vad händer om du indexerar en vy, är den fortfarande en vy?

Varför använda ett täckande index istället för ett sammansatt index?

Spelar antalet dubbletter i en nyckelkolumn någon roll?

Är det möjligt att skapa ett icke-klustrat index på endast en specifik delmängd av en nyckelkolumns data?

Och återigen lite från översättaren

Syftet med uppkomsten av denna översättning på Habrahabrs sidor var att berätta eller påminna dig om SimpleTalk-bloggen från RedGate.
Den publicerar många underhållande och intressanta inlägg.
Jag är inte ansluten till några företagsprodukter RedGate, inte heller med deras försäljning.

Som utlovat, böcker för den som vill veta mer
Jag rekommenderar tre mycket bra böcker från mig själv (länkar leder till tända versioner i butiken Amazon):

Microsoft SQL Server 2012 T-SQL Fundamentals (referens för utvecklare) Författare Itzik Ben-Gan Publiceringsdatum: 15 juli 2012 Författaren, en mästare på sitt hantverk, ger grundläggande kunskaper om att arbeta med databaser. Om du har glömt allt eller aldrig visste så är det definitivt värt att läsa.

Om det finns många poster i tabellen kan det vara mycket svårt att hitta rätt post. Datasökning utförs med en brute-force-metod, det vill säga att alla tabellposter tittas igenom från den första posten till den sista posten, vilket leder till mycket tid. För att göra det lättare att hitta data i en tabell används index. Ett index, ibland kallat en pekare, är sekvensnumret för en post i en tabell. Indexet är byggt baserat på värdena för ett fält eller värden för flera fält. Ett index byggt med hjälp av värdena i ett fält kallas enkelt, och ett index baserat på värdena för två eller flera fält kallas komplext. Under indexkonstruktionen sorteras poster i tabellen efter värdena för fältet (eller fälten) i det framtida indexet. Den första raden i tabellen tilldelas sedan indexnummer ett, den andra raden tilldelas indexnummer två, och så vidare till slutet av tabellen.

Både enkla och komplexa index har sin egen typ (Ture). Primärt (Primärt) index (nyckel) är ett fält eller en grupp av fält som unikt identifierar en post, det vill säga värdena för det primära indexet är unika (upprepas inte). I en relationsdatabas kan varje tabell bara ha en primärnyckel. En tabell kan ha många främmande nycklar och de kommer att ha en av följande typer:

Kandidat - kandidat för primärnyckel eller alternativnyckel. Den har alla egenskaper hos en primärnyckel.

Unik - tillåter dubbletter av värden i fältet som det är byggt på, men endast den första posten från en grupp poster med samma indexfältvärde kommer att visas.

Vanligt - lägger inga begränsningar på värdena i indexfältet och på visningen av poster på skärmen. Indexet styr bara i vilken ordning posterna visas. Detta är den mest populära typen av index.

Relationen mellan tabeller utförs genom index, som kallas nycklar.

Det konstruerade indexet lagras i en speciell indexfil. Om indexfilen endast lagrar ett index, kallas den single-index och har filtillägget .idx. Indexfiler som lagrar många index kallas multiindexfiler och har filtillägget .cdx. Varje index som lagras i en multiindexfil kallas en tagg. Varje tagg har sitt eget unika namn.

Det finns två typer av multiindexfiler: helt enkelt multiindexfiler (beskrivs ovan) och strukturella multiindexfiler. En strukturell multiindexfil har samma namn som tabellen som den tillhör (den enda skillnaden är i filtillägget) och har följande egenskaper:

Öppnas automatiskt med sitt eget bord;

Den kan inte stängas, men den kan inte göras till den huvudsakliga.

En tabell kan ha många indexfiler, både enkelindex och multiindex. Äldre versioner av FoxPro använder Multi-Index-filer.

Skapa ett index

Det finns två sätt att skapa ett index.

A. Använda kommandot:

INDEX PÅ<индексное выражение>DEN DÄR< idx-fil> | MÄRKA<имя тега>

Syftet med alternativen:

<indexuttryck>- namnet på fältet (eller fälten) baserat på de värden som indexet ska byggas av. När du bygger ett komplext index listas fältnamnen separerade av ett + (plus)-tecken. Om ett komplext index är byggt av:

För numeriska fält byggs indexet utifrån summan av fältvärdena;

För teckenfält byggs indexet först enligt värdet på det första fältet, och i händelse av upprepade värden i det första fältet - enligt värdena i det andra fältet; om värdena för det första och andra fältet upprepas - enligt värdena för det tredje fältet, etc.;

För fält av olika typer reduceras först fältvärdena till en typ, vanligtvis tecken, och sedan byggs ett index.

Längden på indexuttrycket får inte överstiga 254 tecken.

DEN DÄR< idx-fil>- namnet på den enda indexfilen anges.

MÄRKA<имя тега> - indikerar namnet på taggen i multiindexfilen. Om alternativet används placeras den skapade taggen i den angivna multiindexfilen, och om den nödvändiga multiindexfilen saknas kommer en strukturell multiindexfil att byggas. Om alternativet utelämnas kommer den skapade taggen att placeras i den aktuella multiindexfilen.

FÖR<условие> - ställer in valläget för indexet för de tabellposter som uppfyller<условию>.

KOMPAKT- styr skapandet av en kompakt enkelindexfil. Äldre versioner av FoxPro använder det inte.

NEDÅTGÅENDE- bygger indexet i fallande ordning. Som standard byggs indexet i stigande ordning (ASCENDING). För enindexfiler kan du bara bygga ett index i stigande ordning. Om du utfärdar kommandot SET COLLATE innan du använder kommandot INDEX ON... kan du bygga en enkelindexfil i fallande ordning.

UNIK- bygger ett unikt index. Om indexfältet/indexfälten innehåller dubbla värden, kommer endast den första posten att inkluderas i indexet och de återstående posterna kommer inte att vara tillgängliga.

TILLSATS- den nyskapade indexfilen stänger inte de indexfiler som redan är öppna vid den tidpunkten. Om alternativet utelämnas stänger den nyskapade indexfilen alla tidigare öppna indexfiler.

b. Använda huvudmenyn:

I det här fallet skapas indexet antingen när tabellen skapas eller när tabellstrukturen ändras. För att göra detta, välj fliken Index (Fig. 3.1) i dialogrutan Tabelldesigner.

Varje index beskrivs med en rad i dialogrutan Tabelldesigner.

Kolumnen Namn anger taggnamnet för multiindexfilen. Om en av multiindexfilerna tidigare har öppnats, placeras det nybyggda indexet i den öppna multiindexfilen. Om indexet byggs samtidigt med skapandet av en tabellfil eller om tabellfilen inte har flerindexfiler, placeras det nybyggda indexet i en automatiskt skapad strukturell multiindexfil.

Kolumnen Ture, utrustad med en rullgardinslista, indikerar en av de giltiga indextyperna. Om indexet är byggt på en tabell som är en del av en databas, så finns det fyra möjliga värden: Primary, Candidate, Unique och Regular. Om indexet är byggt för en ledig tabell, så finns inte det primära värdet i rullgardinsmenyn.

Kolumnen Uttryck listar namnen på de fält vars värden måste användas för att bygga ett index. Om ett komplext index byggs är det bekvämare att använda uttrycksbyggaren, som startas genom att klicka på knappen till höger om inmatningsfältet.

I kolumnen Filter kan du ställa in ett logiskt villkor och bygga ett index inte för alla tabellposter, utan bara för poster som uppfyller filtervillkoret. Denna graf är också utrustad med en uttrycksbyggare. Båda byggarnas innehåll och utseende är desamma (Fig. 3.2).

I fig. Figur 3.2 visar konstruktionen av ett komplext index med två teckenfält ush_step och uch_zvan (taggnamnet uch tilldelades innan uttrycksbyggaren anropades på skärmen). "+"-tecknet som indikerar konstruktionen av ett komplext index tas från rullgardinsmenyn String.

Listrutan String listar giltiga strängfunktioner. Likaså listar matte, logisk och datum giltiga matematiska, logiska och datumfunktioner. Den önskade funktionen från dessa rullgardinslistor väljs genom att klicka med vänster musknapp. Fältnamn (Fältlista) och variabelnamn (Variabellista) väljs genom att dubbelklicka på vänster musknapp. Det resulterande uttrycket placeras i uttrycksfönstret.

Listrutan Från tabell anger namnet på tabellen från vilken fälten tas för att bygga indexet. Om så önskas kan du beställa vilken tabell som helst från den aktuella databasen och ta vilket fält som helst för att bygga ett index.

1) Begreppet index
Indexär ett verktyg som ger snabb åtkomst till tabellrader baserat på värdena i en eller flera kolumner.

Det finns mycket variation i den här operatören eftersom den inte är standardiserad, eftersom standarder inte tar upp prestandaproblem.

2) Skapa index
SKAPA INDEX
PÅ()

3) Ändra och ta bort index
För att kontrollera aktiviteten i indexet används operatören:
ÄNDRA INDEX
För att ta bort ett index, använd operatorn:
SLIPP INDEX

a) Regler för tabellval
1. Det är lämpligt att indexera tabeller där högst 5 % av raderna är valda.
2. Tabeller som inte har dubbletter i WHERE-satsen i SELECT-satsen ska indexeras.
3. Det är inte praktiskt att indexera ofta uppdaterade tabeller.
4. Det är olämpligt att indexera tabeller som inte upptar mer än 2 sidor (för Oracle är detta färre än 300 rader), eftersom hela genomsökningen inte tar längre tid.

b) Regler för kolumnval
1. Primära och främmande nycklar - används ofta för att sammanfoga tabeller, hämta data och söka. Dessa är alltid unika index med maximal användbarhet
2. När du använder referensintegritetsalternativ behöver du alltid ett index på FK.
3. Kolumner som data ofta sorteras och/eller grupperas efter.
4. Kolumner som ofta söks i WHERE-satsen i en SELECT-sats.
5. Du bör inte skapa index på långa beskrivande kolumner.

c) Principer för att skapa sammansatta index
1. Sammansatta index är bra om de enskilda kolumnerna har få unika värden, men ett sammansatt index ger mer unikhet.
2. Om alla värden som valts av SELECT-satsen tillhör ett sammansatt index, väljs värdena från indexet.
3. Ett sammansatt index bör skapas om WHERE-satsen använder två eller flera värden kombinerade med AND-operatorn.

d) Det rekommenderas inte att skapa
Det rekommenderas inte att skapa index på kolumner, inklusive sammansatta sådana, som:
1. Används sällan för att söka, slå samman och sortera frågeresultat.
2. Innehåller ofta växlande värden, vilket kräver frekvent uppdatering av indexet, vilket saktar ner prestandan för databasen.
3. Innehåller ett litet antal unika värden (mindre än 10 % m/f) eller ett övervägande antal rader med ett eller två värden (leverantörens hemort är Moskva).
4. Funktioner eller ett uttryck tillämpas på dem i WHERE-satsen, och indexet fungerar inte.

e) Vi får inte glömma
Du bör sträva efter att minska antalet index, eftersom ett stort antal index minskar hastigheten på datauppdateringen. Därför rekommenderar MS SQL Server att inte skapa fler än 16 index per tabell.
Vanligtvis skapas index för frågeändamål och för att upprätthålla referensintegritet.
Om indexet inte används för frågor, bör det tas bort och referensintegriteten bör säkerställas med hjälp av triggers.

För att ge snabb åtkomst till Oracle DBMS-tabellrader används index. Index ger snabb åtkomst till data under operationer som väljer ett relativt litet antal tabellrader.

Även om Oracle tillåter ett obegränsat antal index på en tabell, är index bara användbara när de används för att påskynda frågor. Annars tar de bara upp utrymme och minskar serverns prestanda vid uppdatering av indexerade kolumner. Du måste använda funktionen EXPLAIN PLAN (exekverings- och statistikplan) för att avgöra hur index används i dina frågor. Ibland, om indexet inte används som standard, kan du använda frågetips för att använda indexet.

Skapa index efter att ha infogat tabelldata

Vanligtvis infogar eller läser du in data i en tabell innan du skapar index. Annars kommer overheaden för att uppdatera index att sakta ner infognings- eller laddningsoperationer. Det enda undantaget från denna regel är ett index på en klusternyckel. Det kan bara skapas för ett tomt kluster.

Byt till tillfälligt tabellutrymme för att undvika problem med ledigt utrymme när du skapar index

När du skapar ett index på en tabell som redan innehåller data kräver Oracle ytterligare minne för sortering. Detta använder det sorteringsminnesområde som tilldelats indexskaparen (beloppet som tilldelas för varje användare ställs in av initialiseringsparametern SORT_AREA_SIZE), dessutom måste Oracle-servern spola och byta information från temporära segment som tilldelats under indexskapandet. Om indexet är mycket stort, rekommenderas att du gör följande:

1. Skapa ett nytt temporärt tabellutrymme med CREATE TABLESPACE-satsen.
2. Ange detta nya temporära utrymme i parametern TEMPORARY TABLESPACE i ALTER USER-satsen.
3. Skapa ett index med CREATE INDEX-satsen.
4. Släpp det här tabellutrymmet med kommandot DROP TABLESPACE. Använd sedan ALTER USER-satsen för att återställa det ursprungliga tabellutrymmet som temporärt.

Välj rätt tabeller och kolumner för indexering

Använd följande riktlinjer för att avgöra när ett index ska skapas.

1. Skapa ett index om du ofta hämtar ett relativt litet antal (mindre än 15%) rader från en stor tabell. Denna procentandel är starkt beroende av den relativa hastigheten för tabellskanningen och hur klustrad raddata är i indexnyckeln. Ju högre surfhastighet, desto lägre procentandel, ju mer klustrad raddata är, desto högre procentandel.
2. Indexkolumner som används i sammanfogningar för att förbättra prestandan för att sammanfoga flera tabeller.
3. Index skapas automatiskt baserat på de primära och unika nycklarna.
4. Små tabeller behöver inte indexeras. Om du märker att frågekörningstiden har ökat avsevärt, har den troligen blivit stor.

• värdena i kolumnen är relativt unika;
• stort utbud av värden (lämplig för vanliga index);
• litet värdeområde (lämplig för bitindex);
• mycket glesa kolumner (många odefinierade, "tomma" värden), men frågor handlar mest om meningsfulla rader. I det här fallet är en jämförelse som matchar alla icke-nullvärden att föredra:
  WHERE COL_X > -9,99 *power(10, 125) istället för
  WHERE COL_X INTE ÄR NULL Detta beror på att det första fallet använder COL_X-indexet (förutsatt att COL_X-kolumnen är en numerisk typ).

Begränsa antalet index per tabell

Ju fler index, desto högre blir omkostnaden vid ändring av en tabell. När rader läggs till eller tas bort uppdateras alla index i tabellen. När en kolumn uppdateras måste även alla index som den deltar i uppdateras.

När det gäller index måste du väga prestandavinsterna för frågor kontra prestandastraffen för uppdateringar. Till exempel, om tabellen huvudsakligen är skrivskyddad, kan du använda index i stor utsträckning; men om tabellen uppdateras ofta, är det tillrådligt att minimera användningen av index.

Välj ordningen på kolumner i sammansatta index

Även om kolumner kan anges i valfri ordning i CREATE INDEX-satsen, kan ordningen på kolumnerna i CREATE INDEX-satsen påverka frågeprestanda. I allmänhet listas de kolumner som kommer att användas oftast först i indexet. Du kan skapa ett sammansatt index (med flera kolumner), som kan användas för att fråga alla kolumner som ingår i indexet eller bara några.

Samla statistik för korrekt användning av index

Index kan användas mer effektivt om databasen samlar in och underhåller statistik om de tabeller som används i frågor. Du kan samla in statistik under indexskapandet genom att ange nyckelordet COMPUTE STATISTICS i CREATE INDEX-satsen. Eftersom data ständigt uppdateras och fördelningen av värden ändras, bör statistik uppdateras regelbundet med DBMS_STATS.GATHER_TABLE_STATISTICS- och DBMS_STATS.GATHER_SCHEMA_STATISTICS-procedurerna.

Förstör onödiga index

Indexet raderas i följande fall:

• om användningen av ett index inte förbättrar frågeprestanda. Denna situation uppstår om tabellen är för liten eller om tabellen har många rader, men få av dem är indexposter;
• om dina förfrågningar om förslag inte använder indexet;
• om indexet också tas bort innan det byggs om.

Och index, det här speciella uppslagstabeller, som en databassökmotor kan använda för att påskynda datahämtningen. Enkelt uttryckt är ett index en pekare till data i en tabell. Indexet i databasen är mycket likt indexet längst bak i boken.

Om du till exempel vill ha länkar till alla sidor i en bok om ett visst ämne, konsultera först indexet, som listar alla ämnen i alfabetisk ordning och sedan hänvisar till ett eller flera specifika sidnummer.

Indexet hjälper till att påskynda frågor och meningar, men det saktar ner datainmatningen, med uttalanden UPPDATERING Och FÖRA IN. Index kan skapas eller raderas utan att data påverkas.

Att skapa ett index innebär ett uttalande SKAPA INDEX, som låter dig namnge ett index för att specificera tabellen och vilken eller vilka kolumner som ska indexeras och för att indikera om indexet är i stigande eller fallande ordning.

Index kan också vara unika, med begränsningen UNIK, så att indexet förhindrar dubbletter av poster i en kolumn eller kombination av kolumner som har ett index på sig.

CREATE INDEX kommandot

Grundläggande syntax SKAPA INDEX som följer:

CREATE INDEX index_name ON table_name;

Index med en kolumn

Ett enda kolumnindex skapas på endast en kolumn i tabellen. Den grundläggande syntaxen är som följer.

CREATE INDEX index_name ON table_name(column_name);

Unika index

Unika index används inte bara för drift, utan också för att säkerställa dataintegritet. Ett unikt index tillåter inte att några dubbletter av värden infogas i tabellen. Den grundläggande syntaxen är som följer.

SKAPA UNIKT INDEX index_name on table_name(column_name);

Sammansatta index

Ett sammansatt index är ett index på två eller flera kolumner i en tabell. Dess grundläggande syntax är följande.

CREATE INDEX index_name on table_name(column1, column2);

Oavsett om du skapar ett index på en enskild kolumn eller ett sammansatt index, ta hänsyn till kolumnen/kolumnerna som du kan använda väldigt ofta i en WHERE-fråga som ett filtervillkor.

Om det bara finns en kolumn i bruk måste ett index väljas på en kolumn. Om det finns två eller flera kolumner som ofta används som filter i WHERE-satsen, skulle ett sammansatt index vara ett bättre val.

Implicita index

Implicita index är index som skapas automatiskt på databasservern när ett objekt skapas. Index skapas automatiskt på primärnyckeln och den unika begränsningen.

DROP INDEX kommando

Index kan raderas med SQL-kommandot SLÄPPA. Du bör vara försiktig när du tar bort ett index eftersom prestandan antingen kan vara långsammare eller bättre.

Den grundläggande syntaxen är följande:

SLÄPP INDEX index_name;

Du kan titta på INDEX-begränsningsexemplet för att se några riktiga exempel på index.

När bör du undvika index?

Även om index är avsedda att förbättra databasens prestanda, finns det tillfällen då de bör undvikas.

Följande instruktioner anger när indexanvändning bör omprövas.

• Index bör inte användas på små tabeller.
• Tabeller som ofta har stora uppdateringar eller infogningsåtgärder.
• Index bör inte användas på kolumner som innehåller ett stort antal nollvärden.
• Kolumner som manipuleras ofta bör inte indexeras.