Gli indici del database vengono utilizzati per migliorare la velocità delle operazioni del database in una tabella con un numero elevato di record. Gli indici di database (sia gli indici cluster che gli indici non cluster) sono abbastanza simili agli indici dei libri nelle loro funzionalità. Un indice del libro ti consente di andare direttamente ai diversi argomenti discussi nel libro. Se vuoi cercare un argomento specifico, vai semplicemente all'indice, trova il numero di pagina che contiene l'argomento che stai cercando e poi puoi andare direttamente a quella pagina. Senza un indice, dovresti cercare l'intero libro.
Gli indici del database funzionano allo stesso modo. Senza gli indici dovresti cercare nell'intera tabella per eseguire un'operazione specifica sul database. Con gli indici, non è necessario eseguire la scansione di tutti i record della tabella. L'indice punta direttamente al record che stai cercando, riducendo notevolmente il tempo di esecuzione della query.
Gli indici di SQL Server possono essere suddivisi in due tipi principali:
- Indici raggruppati
- Indici non cluster
In questo articolo, esamineremo cosa sono gli indici cluster e non, come vengono creati e quali sono le principali differenze tra i due. Vedremo anche quando usare indici cluster o non cluster in SQL Server.
Iniziamo innanzitutto con un indice cluster.
Indice raggruppato
Un indice cluster è un indice che definisce l'ordine fisico in cui i record della tabella sono archiviati in un database. Poiché può esistere un solo modo in cui i record vengono archiviati fisicamente in una tabella di database, può esistere un solo indice cluster per tabella. Per impostazione predefinita, viene creato un indice cluster su una colonna di chiave primaria.
Indici cluster predefiniti
Creiamo una tabella fittizia con la colonna della chiave primaria per vedere l'indice cluster predefinito. Esegui il seguente script:
CREATE DATABASE Hospital
CREATE TABLE Patients
(
id INT PRIMARY KEY,
name VARCHAR(50) NOT NULL,
gender VARCHAR(50) NOT NULL,
age INT NOT NULL
)
Lo script precedente crea un database fittizio Hospital. Il database ha 4 colonne:id, nome, sesso, età. La colonna id è la colonna della chiave primaria. Quando viene eseguito lo script precedente, viene creato automaticamente un indice cluster nella colonna id. Per vedere tutti gli indici in una tabella, puoi utilizzare la procedura memorizzata "sp_helpindex".
USE Hospital
EXECUTE sp_helpindex Patients
Ecco l'output:
Puoi vedere il nome dell'indice, la descrizione e la colonna su cui è stato creato l'indice. Se aggiungi un nuovo record alla tabella Pazienti, verrà memorizzato in ordine crescente rispetto al valore nella colonna id. Se il primo record inserito nella tabella ha un ID di tre, il record verrà archiviato nella terza riga anziché nella prima riga poiché l'indice cluster mantiene l'ordine fisico.
Indici cluster personalizzati
Puoi creare i tuoi indici cluster. Tuttavia, prima di poterlo fare, devi creare l'indice cluster esistente. Abbiamo un indice cluster a causa della colonna della chiave primaria. Se rimuoviamo il vincolo della chiave primaria, il cluster predefinito verrà rimosso. Lo script seguente rimuove il vincolo della chiave primaria.
USE Hospital
ALTER TABLE Patients
DROP CONSTRAINT PK__Patients__3213E83F3DFAFAAD
GO
Lo script seguente crea un indice personalizzato "IX_tblPatient_Age" nella colonna età della tabella Pazienti. Grazie a questo indice, tutti i record nella tabella Pazienti verranno archiviati in ordine crescente di età.
use Hospital
CREATE CLUSTERED INDEX IX_tblPatient_Age
ON Patients(age ASC)
Aggiungiamo ora alcuni record fittizi nella tabella Pazienti per vedere se sono effettivamente inseriti in ordine crescente di età:
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)
Nello script sopra, aggiungiamo 5 record fittizi. Notare i valori per la colonna età. Hanno valori casuali e non sono in alcun ordine logico. Tuttavia, poiché abbiamo creato un indice cluster, i record verranno effettivamente inseriti nell'ordine crescente del valore nella colonna età. Puoi verificarlo selezionando tutti i record dalla tabella Pazienti.
SELECT * FROM Patients
Ecco l'output:
Puoi vedere che i record sono ordinati in ordine crescente rispetto ai valori nella colonna età.
Indici non cluster
Un indice non cluster viene utilizzato anche per velocizzare le operazioni di ricerca. A differenza di un indice cluster, un indice non cluster non definisce fisicamente l'ordine in cui i record vengono inseriti in una tabella. In effetti, un indice non cluster viene archiviato in una posizione separata dalla tabella di dati. Un indice non cluster è come un indice di un libro, che si trova separatamente dai contenuti principali del libro. Poiché gli indici non in cluster si trovano in una posizione separata, possono esserci più indici non in cluster per tabella.
Per creare un indice non cluster, è necessario utilizzare l'istruzione "CREATE NONCLUSTERED". Il resto della sintassi rimane la stessa della sintassi per la creazione di un indice cluster. Lo script seguente crea un indice non cluster "IX_tblPatient_Name" che ordina i record in ordine crescente rispetto al nome.
use Hospital
CREATE NONCLUSTERED INDEX IX_tblPatient_Name
ON Patients(name ASC)
Lo script di cui sopra creerà un indice che contiene i nomi dei pazienti e l'indirizzo dei loro record corrispondenti come mostrato di seguito:
Nome | Indirizzo record |
Ana | Indirizzo record |
Jon | Indirizzo record |
Mike | Indirizzo record |
Nick | Indirizzo record |
Sara | Indirizzo record |
Qui, l'"Indirizzo del record" in ciascuna riga è il riferimento ai record della tabella effettivi per i pazienti con i nomi corrispondenti.
Ad esempio, se si desidera recuperare l'età e il sesso del paziente denominato "Mike", il database cercherà prima "Mick" nell'indice non cluster "IX_tblPatient_Name" e dall'indice non cluster recupererà il riferimento del record effettivo e lo utilizzerà per restituire l'età e il sesso effettivi del paziente denominato "Mike"
Poiché un database deve effettuare due ricerche, prima nell'indice non cluster e poi nella tabella effettiva, gli indici non cluster possono essere più lenti per le operazioni di ricerca. Tuttavia, per le operazioni INSERT e UPDATE, gli indici non cluster sono più veloci poiché l'ordine dei record deve essere aggiornato solo nell'indice e non nella tabella effettiva.
Quando utilizzare indici cluster o non cluster
Ora che conosci le differenze tra un indice cluster e uno non cluster, vediamo i diversi scenari per l'utilizzo di ciascuno di essi.
1. Numero di indici
Questo è abbastanza ovvio. Se devi creare più indici nel tuo database, scegli l'indice non cluster poiché può esserci un solo indice cluster.
2. SELEZIONA Operazioni
Se si desidera selezionare solo il valore dell'indice utilizzato per creare e indicizzare, gli indici non in cluster sono più veloci. Ad esempio, se hai creato un indice nella colonna "nome" e desideri selezionare solo il nome, gli indici non raggruppati restituiranno rapidamente il nome.
Tuttavia, se si desidera selezionare altri valori di colonna come età, sesso utilizzando l'indice dei nomi, l'operazione SELECT sarà più lenta poiché prima verrà ricercato il nome dall'indice e quindi verrà utilizzato il riferimento al record della tabella effettivo per la ricerca l'età e il sesso.
D'altra parte, con indici cluster poiché tutti i record sono già ordinati, l'operazione SELECT è più veloce se i dati vengono selezionati da colonne diverse dalla colonna con indice cluster.
3. INSERT/UPDATE Operazioni
Le operazioni INSERT e UPDATE sono più veloci con indici non cluster poiché non è necessario che i record effettivi vengano ordinati quando viene eseguita un'operazione INSERT o UPDATE. Piuttosto solo l'indice non cluster deve essere aggiornato.
4. Spazio su disco
Poiché gli indici non in cluster vengono archiviati in una posizione separata rispetto alla tabella originale, gli indici non in cluster consumano spazio su disco aggiuntivo. Se lo spazio su disco è un problema, utilizzare un indice cluster.
5. Verdetto finale
Come regola pratica, ogni tabella dovrebbe avere almeno un indice cluster preferibilmente sulla colonna utilizzata per SELECTING record e contiene valori univoci. La colonna della chiave primaria è un candidato ideale per un indice cluster.
D'altra parte, le colonne che sono spesso coinvolte nelle query INSERT e UPDATE dovrebbero avere un indice non cluster presupponendo che lo spazio su disco non sia un problema.