Les index de base de données sont utilisés pour améliorer la vitesse des opérations de base de données dans une table avec un grand nombre d'enregistrements. Les index de base de données (à la fois les index clusterisés et les index non clusterisés) sont assez similaires aux index de livres dans leur fonctionnalité. Un index du livre vous permet d'accéder directement aux différents sujets abordés dans le livre. Si vous souhaitez rechercher un sujet spécifique, il vous suffit d'aller dans l'index, de trouver le numéro de page contenant le sujet que vous recherchez, puis d'accéder directement à cette page. Sans index, il faudrait chercher dans tout le livre.

Les index de base de données fonctionnent de la même manière. Sans index, vous auriez à rechercher dans toute la table afin d'effectuer une opération de base de données spécifique. Avec les index, vous n'avez pas à parcourir tous les enregistrements de la table. L'index vous dirige directement vers l'enregistrement que vous recherchez, ce qui réduit considérablement le temps d'exécution de votre requête.

Les index SQL Server peuvent être divisés en deux types principaux :

1. Index clusterisés
2. Index non clusterisés

Dans cet article, nous verrons ce que sont les index cluster et non cluster, comment ils sont créés et quelles sont les principales différences entre les deux. Nous examinerons également quand utiliser des index clusterisés ou non clusterisés dans SQL Server.

Commençons d'abord avec un index clusterisé.

Index clusterisé

Un index clusterisé est un index qui définit l'ordre physique dans lequel les enregistrements de table sont stockés dans une base de données. Puisqu'il ne peut y avoir qu'une seule façon de stocker physiquement les enregistrements dans une table de base de données, il ne peut y avoir qu'un seul index clusterisé par table. Par défaut, un index clusterisé est créé sur une colonne de clé primaire.

Index clusterisés par défaut

Créons une table factice avec une colonne de clé primaire pour voir l'index clusterisé par défaut. Exécutez le script suivant :

CREATE DATABASE Hospital

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


Le script ci-dessus crée une base de données factice Hospital. La base de données comporte 4 colonnes :id, name, gender, age. La colonne id est la colonne de clé primaire. Lorsque le script ci-dessus est exécuté, un index clusterisé est automatiquement créé sur la colonne id. Pour voir tous les index d'une table, vous pouvez utiliser la procédure stockée "sp_helpindex".

USE Hospital
EXECUTE sp_helpindex Patients

Voici le résultat :

Vous pouvez voir le nom de l'index, sa description et la colonne sur laquelle l'index est créé. Si vous ajoutez un nouvel enregistrement à la table Patients, il sera stocké dans l'ordre croissant de la valeur dans la colonne id. Si le premier enregistrement que vous insérez dans la table a un identifiant de trois, l'enregistrement sera stocké dans la troisième ligne au lieu de la première ligne puisque l'index clusterisé maintient l'ordre physique.

Index groupés personnalisés

Vous pouvez créer vos propres index clusterisés. Cependant, avant de pouvoir le faire, vous devez créer l'index clusterisé existant. Nous avons un index clusterisé en raison de la colonne de clé primaire. Si nous supprimons la contrainte de clé primaire, le cluster par défaut sera supprimé. Le script suivant supprime la contrainte de clé primaire.

USE Hospital
ALTER TABLE Patients
DROP CONSTRAINT PK__Patients__3213E83F3DFAFAAD
GO

Le script suivant crée un index personnalisé "IX_tblPatient_Age" sur la colonne d'âge de la table Patients. Grâce à cet index, tous les enregistrements de la table Patients seront stockés par ordre croissant d'âge.


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


Ajoutons maintenant quelques enregistrements fictifs dans la table Patients pour voir s'ils sont réellement insérés dans l'ordre croissant d'âge :

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)


Dans le script ci-dessus, nous ajoutons 5 enregistrements factices. Notez les valeurs de la colonne d'âge. Ils ont des valeurs aléatoires et ne sont pas dans un ordre logique. Cependant, puisque nous avons créé un index clusterisé, les enregistrements seront en fait insérés dans l'ordre croissant de la valeur dans la colonne d'âge. Vous pouvez le vérifier en sélectionnant tous les enregistrements de la table Patients.

SELECT * FROM Patients

Voici le résultat :

Vous pouvez voir que les enregistrements sont classés dans l'ordre croissant des valeurs de la colonne d'âge.

Index non clusterisés

Un index non clusterisé est également utilisé pour accélérer les opérations de recherche. Contrairement à un index clusterisé, un index non clusterisé ne définit pas physiquement l'ordre dans lequel les enregistrements sont insérés dans une table. En fait, un index non clusterisé est stocké dans un emplacement distinct de la table de données. Un index non clusterisé est comme un index de livre, qui est situé séparément du contenu principal du livre. Étant donné que les index non clusterisés sont situés dans un emplacement distinct, il peut y avoir plusieurs index non clusterisés par table.

Pour créer un index non clusterisé, vous devez utiliser l'instruction « CREATE NONCLUSTERED ». Le reste de la syntaxe reste identique à la syntaxe de création d'un index clusterisé. Le script suivant crée un index non clusterisé "IX_tblPatient_Name" qui trie les enregistrements dans l'ordre croissant du nom.

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



Le script ci-dessus créera un index contenant les noms des patients et l'adresse de leurs enregistrements correspondants, comme indiqué ci-dessous :

Ici, "l'adresse d'enregistrement" dans chaque ligne est la référence aux enregistrements de table réels pour les patients avec les noms correspondants.

Par exemple, si vous souhaitez récupérer l'âge et le sexe du patient nommé "Mike", la base de données recherchera d'abord "Mick" dans l'index non clusterisé "IX_tblPatient_Name" et à partir de l'index non clusterisé, il récupérera la référence réelle de l'enregistrement. et l'utilisera pour renvoyer l'âge et le sexe réels du patient nommé "Mike"

Étant donné qu'une base de données doit effectuer deux recherches, d'abord dans l'index non clusterisé, puis dans la table elle-même, les index non clusterisés peuvent être plus lents pour les opérations de recherche. Cependant, pour les opérations INSERT et UPDATE, les index non clusterisés sont plus rapides car l'ordre des enregistrements ne doit être mis à jour que dans l'index et non dans la table réelle.

Quand utiliser des index clusterisés ou non clusterisés

Maintenant que vous connaissez les différences entre un index cluster et un index non cluster, voyons les différents scénarios d'utilisation de chacun d'eux.

1. Nombre d'index

C'est assez évident. Si vous devez créer plusieurs index sur votre base de données, optez pour un index non clusterisé car il ne peut y avoir qu'un seul index clusterisé.

2. Opérations SELECT

Si vous souhaitez sélectionner uniquement la valeur d'index utilisée pour créer et indexer, les index non clusterisés sont plus rapides. Par exemple, si vous avez créé un index sur la colonne "nom" et que vous souhaitez sélectionner uniquement le nom, les index non cluster renverront rapidement le nom.

Cependant, si vous souhaitez sélectionner d'autres valeurs de colonne telles que l'âge, le sexe à l'aide de l'index des noms, l'opération SELECT sera plus lente car le nom sera d'abord recherché à partir de l'index, puis la référence à l'enregistrement réel de la table sera utilisée pour rechercher l'âge et le sexe.

D'autre part, avec les index clusterisés puisque tous les enregistrements sont déjà triés, l'opération SELECT est plus rapide si les données sont sélectionnées dans des colonnes autres que la colonne avec index clusterisé.

3. Opérations INSERT/UPDATE

Les opérations INSERT et UPDATE sont plus rapides avec des index non clusterisés car il n'est pas nécessaire de trier les enregistrements réels lorsqu'une opération INSERT ou UPDATE est effectuée. Seul l'index non clusterisé doit être mis à jour.

4. Espace disque

Étant donné que les index non clusterisés sont stockés à un emplacement distinct de la table d'origine, les index non clusterisés consomment de l'espace disque supplémentaire. Si l'espace disque est un problème, utilisez un index clusterisé.

5. Verdict final

En règle générale, chaque table doit avoir au moins un index clusterisé de préférence sur la colonne qui est utilisée pour SELECTIONNER les enregistrements et contient des valeurs uniques. La colonne de clé primaire est un candidat idéal pour un index clusterisé.

D'autre part, les colonnes qui sont souvent impliquées dans les requêtes INSERT et UPDATE doivent avoir un index non clusterisé en supposant que l'espace disque n'est pas un problème.