Databasindex används för att förbättra hastigheten på databasoperationer i en tabell med ett stort antal poster. Databasindex (både klustrade index och icke-klustrade index) är ganska lika bokindex i sin funktionalitet. Ett bokregister låter dig gå direkt till de olika ämnen som diskuteras i boken. Om du vill söka på ett specifikt ämne går du bara till index, hittar sidnumret som innehåller ämnet som du letar efter och kan sedan gå direkt till den sidan. Utan ett index skulle du behöva söka i hela boken.

Databasindex fungerar på samma sätt. Utan index skulle du behöva söka i hela tabellen för att utföra en specifik databasoperation. Med index behöver du inte skanna igenom alla tabellposter. Indexet pekar dig direkt till posten som du söker efter, vilket avsevärt minskar körningstiden för din fråga.

SQL Server-index kan delas in i två huvudtyper:

1. Klustrade index
2. Icke-klustrade index

I den här artikeln kommer vi att titta på vad klustrade och icke-klustrade index är, hur de skapas och vad de huvudsakliga skillnaderna mellan de två är. Vi kommer också att titta på när man ska använda klustrade eller icke-klustrade index i SQL Server.

Låt oss först börja med ett klustrat index.

Klustrat index

Ett klustrat index är ett index som definierar den fysiska ordningen i vilken tabellposter lagras i en databas. Eftersom det bara kan finnas ett sätt på vilket poster fysiskt lagras i en databastabell, kan det bara finnas ett klustrat index per tabell. Som standard skapas ett klustrat index på en primärnyckelkolumn.

Standard klustrade index

Låt oss skapa en dummytabell med primärnyckelkolumn för att se standardklustrade index. Kör följande skript:

CREATE DATABASE Hospital

CREATE TABLE Patients
(
id INT PRIMARY KEY,
name VARCHAR(50) NOT NULL,
gender VARCHAR(50) NOT NULL,
age INT NOT NULL
)


Skriptet ovan skapar en dummydatabas Hospital. Databasen har 4 kolumner:id, namn, kön, ålder. Id-kolumnen är den primära nyckelkolumnen. När ovanstående skript körs skapas automatiskt ett klustrat index i id-kolumnen. För att se alla index i en tabell kan du använda den lagrade proceduren "sp_helpindex".

USE Hospital
EXECUTE sp_helpindex Patients

Här är resultatet:

Du kan se indexnamn, beskrivning och kolumnen där indexet skapas. Om du lägger till en ny post i tabellen Patienter, kommer den att lagras i stigande ordning efter värdet i id-kolumnen. Om den första posten du infogar i tabellen har ett ID på tre, kommer posten att lagras i den tredje raden istället för den första raden eftersom klustrade index bibehåller fysisk ordning.

Anpassade klustrade index

Du kan skapa dina egna klustrade index. Men innan du kan göra det måste du skapa det befintliga klustrade indexet. Vi har ett klustrat index på grund av primärnyckelkolumn. Om vi ​​tar bort den primära nyckelbegränsningen kommer standardklustret att tas bort. Följande skript tar bort den primära nyckelbegränsningen.

USE Hospital
ALTER TABLE Patients
DROP CONSTRAINT PK__Patients__3213E83F3DFAFAAD
GO

Följande skript skapar ett anpassat index "IX_tblPatient_Age" i ålderskolumnen i tabellen Patienter. På grund av detta index kommer alla poster i patienttabellen att lagras i stigande ordning efter ålder.


use Hospital
CREATE CLUSTERED INDEX IX_tblPatient_Age
ON Patients(age ASC)


Låt oss nu lägga till några dummy-poster i patienttabellen för att se om de faktiskt är infogade i stigande åldersordning:

USE Hospital

INSERT INTO Patients

VALUES
(1, 'Sara', 'Female', 34),
(2, 'Jon', 'Male', 20),
(3, 'Mike', 'Male', 54),
(4, 'Ana', 'Female', 10),
(5, 'Nick', 'Female', 29)


I skriptet ovan lägger vi till 5 dummy-poster. Lägg märke till värdena för ålderskolumnen. De har slumpmässiga värden och är inte i någon logisk ordning. Men eftersom vi har skapat ett klustrat index, kommer posterna faktiskt att infogas i stigande ordning för värdet i ålderskolumnen. Du kan verifiera detta genom att välja alla poster från patienttabellen.

SELECT * FROM Patients

Här är resultatet:

Du kan se att poster är ordnade i stigande ordning av värdena i ålderskolumnen.

Icke-klustrade index

Ett icke-klustrat index används också för att påskynda sökoperationer. Till skillnad från ett klustrat index definierar ett icke-klustrat index inte fysiskt i vilken ordning poster infogas i en tabell. Faktum är att ett icke-klustrat index lagras på en separat plats från datatabellen. Ett icke-klustrat register är som ett bokregister, som är placerat separat från bokens huvudinnehåll. Eftersom icke-klustrade index finns på en separat plats, kan det finnas flera icke-klustrade index per tabell.

För att skapa ett icke-klustrat index måste du använda "CREATE NONCLUSTERED"-satsen. Resten av syntaxen förblir densamma som syntaxen för att skapa ett klustrat index. Följande skript skapar ett icke-klustrat index "IX_tblPatient_Name" som sorterar posterna i stigande ordning efter namnet.

use Hospital
CREATE NONCLUSTERED INDEX IX_tblPatient_Name
ON Patients(name ASC)



Ovanstående skript kommer att skapa ett index som innehåller namnen på patienterna och adressen till deras motsvarande register som visas nedan:

Här är "Rekordsadressen" i varje rad referensen till de faktiska tabellposterna för patienterna med motsvarande namn.

Till exempel, om du vill hämta ålder och kön på patienten som heter "Mike", kommer databasen först att söka efter "Mick" i det icke-klustrade indexet "IX_tblPatient_Name" och från det icke-klustrade indexet kommer den att hämta den faktiska postreferensen och kommer att använda det för att returnera faktisk ålder och kön på patienten som heter "Mike"

Eftersom en databas måste göra två sökningar, först i det icke-klustrade indexet och sedan i den faktiska tabellen, kan icke-klustrade index vara långsammare för sökoperationer. Men för INSERT- och UPDATE-operationer är icke-klustrade index snabbare eftersom ordningen på posterna bara behöver uppdateras i indexet och inte i den faktiska tabellen.

När ska man använda klustrade eller icke-klustrade index

Nu när du känner till skillnaderna mellan ett klustrat och ett icke-klustrat index, låt oss se de olika scenarierna för att använda var och en av dem.

1. Antal index

Detta är ganska uppenbart. Om du behöver skapa flera index på din databas, välj icke-klustrade index eftersom det bara kan finnas ett klustrat index.

2. VÄLJ operationer

Om du bara vill välja det indexvärde som används för att skapa och indexera, är icke-klustrade index snabbare. Om du till exempel har skapat ett index i kolumnen "namn" och du bara vill välja namnet, kommer icke-klustrade index snabbt att returnera namnet.

Men om du vill välja andra kolumnvärden som ålder, kön med hjälp av namnindex, kommer SELECT-operationen att gå långsammare eftersom först namnet kommer att sökas från indexet och sedan referensen till den faktiska tabellposten kommer att användas för att söka ålder och kön.

Å andra sidan, med klustrade index eftersom alla poster redan är sorterade, är SELECT-operationen snabbare om data väljs från andra kolumner än kolumnen med klustrade index.

3. INFOGA/UPPDATERA Operationer

INSERT- och UPDATE-operationerna är snabbare med icke-klustrade index eftersom de faktiska posterna inte behöver sorteras när en INSERT- eller UPDATE-operation utförs. Snarare behöver bara det icke-klustrade indexet uppdateras.

4. Diskutrymme

Eftersom icke-klustrade index lagras på en annan plats än den ursprungliga tabellen, förbrukar icke-klustrade index ytterligare diskutrymme. Om diskutrymme är ett problem, använd ett klustrat index.

5. Slutlig dom

Som en tumregel bör varje tabell ha minst ett klustrat index, helst på kolumnen som används för att VÄLJA poster och som innehåller unika värden. Den primära nyckelkolumnen är en idealisk kandidat för ett klustrat index.

Å andra sidan bör kolumner som ofta är involverade i INSERT- och UPDATE-frågor ha ett icke-klustrat index förutsatt att diskutrymme inte är ett problem.