Cinq principales considérations pour la conception d'index de base de données dans SQL Server

Les index de base de données sont utilisés pour accélérer différentes opérations de table. Cependant avant de créer un index, il est important de savoir si vous avez vraiment besoin d'un index ? Et si vous avez besoin de créer un index, quels sont les points importants à garder à l'esprit ? C'est là qu'intervient la conception d'index de base de données.

Cet article vise à répondre à ces questions sur la conception d'un index de base de données et à éclairer certaines des principales considérations qu'un développeur de base de données doit prendre en compte lors de la conception d'un index.

1. Taille du tableau

La première question qu'un développeur de base de données doit se poser avant de créer un index est de savoir si la table est suffisamment volumineuse pour utiliser efficacement les index. Si la taille de la table est petite, le moteur SQL Server peut analyser la table complète plus rapidement que la recherche dans la table via un index. Les index dans ce cas n'ont aucune utilité et créent une surcharge lors de l'exécution des opérations de base de données.

2. Types de colonnes

Les index doivent être créés sur une colonne de clé primaire ou sur toute colonne contenant des valeurs uniques et ayant une contrainte NOT NULL. De plus, il est conseillé de créer des index sur des colonnes numériques car les colonnes numériques ont tendance à avoir plus de valeurs uniques que les colonnes non numériques. Une mauvaise conception d'index de base de données utilise des index sur des colonnes qui ont très peu d'entrées uniques et peuvent entraîner des requêtes très longues.

Considérez une table nommée Patients qui contient des centaines de milliers d'enregistrements. La table Patients contiendrait une colonne appelée "Sexe" qui ne peut avoir que deux valeurs uniques "Male" et "Female". Si vous créez un index sur la "Colonne Genre", les enregistrements seront triés par ordre alphabétique croissant ou décroissant.

Donc, si vous avez un million d'enregistrements dans la table Patients et que le nombre de patients masculins et féminins est égal, dans l'index, le premier demi-million d'enregistrements aura un sexe « Femme » et le second demi-million aura le sexe « Homme ». Maintenant, si vous souhaitez rechercher une femme qui existe à la 490 000e ligne des enregistrements féminins, le moteur SQL Server devra parcourir 490 000 enregistrements. D'autre part, avec des valeurs numériques uniques, la recherche peut être extrêmement rapide car les index SQL Server sont stockés sous la forme d'arbres B +, et ainsi les valeurs numériques dans les nœuds d'arbre peuvent accélérer les opérations de base de données.

3. Nombre d'index

Officiellement, vous pouvez créer un index cluster et autant d'index non cluster que vous le souhaitez pour chaque table de base de données. Cependant, une bonne conception d'index de base de données consiste à créer un index clusterisé et un nombre limité d'index non clusterisés absolument nécessaires. La création d'un trop grand nombre d'index non clusterisés peut en réalité ralentir les opérations de mise à jour et d'insertion, car lorsqu'un enregistrement est mis à jour ou inséré et qu'une valeur de colonne est modifiée, tous les index associés doivent être mis à jour.

Considérons un scénario dans lequel nous avons deux index non clusterisés, le premier index trie les enregistrements par âge et le second index trie les enregistrements par sexe et par âge.

Voici le premier indice :

Et voici le second :

Maintenant, si un enregistrement avec 40 ans doit être mis à jour à 15 ans pour une raison quelconque, le premier index devra être mis à jour pour déplacer l'enregistrement de la 7e position (40) à la deuxième position afin de garder l'index trié. De même, dans le deuxième index, l'enregistrement du 4e index sera déplacé vers le deuxième index. De nombreux remaniements doivent avoir lieu. Par conséquent, il est sage de limiter au minimum le nombre d'index pour les colonnes régulièrement mises à jour lors de la réflexion sur la conception des index de base de données. De plus, une colonne ne doit pas être utilisée dans plusieurs index non clusterisés.

4. Emplacement de stockage des index

L'emplacement de stockage d'un index peut affecter les performances des requêtes qui utilisent l'index et fait donc également partie d'une bonne conception d'index de base de données. Par défaut, un index clusterisé est stocké dans le même groupe de fichiers que la table sur laquelle l'index est créé. Pour les index non clusterisés, l'index peut être stocké dans le même groupe de fichiers ou dans différents groupes de fichiers couvrant plusieurs lecteurs de disque. Les performances des requêtes des index non clusterisés peuvent être considérablement améliorées en stockant les index non clusterisés sur plusieurs lecteurs de disque. En effet, les performances d'entrée/sortie de la requête seront améliorées du fait de la distribution des données sur différentes zones du lecteur.

L'emplacement de stockage par défaut des index peut également être modifié en spécifiant une valeur pour l'option FILLFACTOR. Étant donné que les index sont physiquement stockés sous la forme d'arbres B +, les données d'index sont stockées sur des pages feuilles. Avec l'option FILLFACTOR, vous pouvez définir le pourcentage de pages de niveau feuille à remplir. Par exemple, si vous définissez la valeur de FILLFACTOR sur 70 %, seuls 70 % de l'espace total de la page de niveau feuille seront remplis par les données d'index. Les 30 % restants seront laissés à la croissance automatique des données d'index à l'avenir.

5. Types d'index

Une autre considération extrêmement importante dans la conception d'un index de base de données est le type d'index à utiliser. Dans un article précédent (ajoutez un lien vers l'article "Quand utiliser un index clusterisé ou non clusterisé"), j'ai expliqué la différence entre les index clusterisés et non clusterisés. J'ai également expliqué ce qu'ils sont et comment ils peuvent être utilisés. La décision de choisir un index clusterisé ou non clusterisé est cruciale et doit être mûrement réfléchie.

Les points suivants doivent être gardés à l'esprit lors du choix du type d'index.

1. Pour les colonnes utilisées dans les requêtes SELECT/JOIN/GROUP BY/BETWEEN, utilisez des index clusterisés.
2. Utilisez des index non clusterisés pour les colonnes où vous souhaitez uniquement récupérer les valeurs de cette colonne spécifique et non des autres colonnes de la même ligne. Les requêtes SELECT qui récupèrent plusieurs enregistrements à l'aide d'un index non clusterisé peuvent être lentes car le moteur SQL Server recherche d'abord les valeurs de colonne sur lesquelles l'index est créé, puis en utilisant la référence de ligne pour la valeur de colonne, les enregistrements des tables de base de données réelles sont récupérés .
3. Pour les colonnes qui subissent souvent des opérations INSERT et UPDATE, utilisez un index non clusterisé. Assurez-vous de ne pas utiliser une colonne dans plusieurs index non clusterisés car cela peut ralentir les requêtes de mise à jour. Les index clusterisés peuvent être lents pour les opérations INSERT/UPDATE car la ligne complète doit être mise à jour au lieu d'une seule valeur de colonne comme c'est le cas avec les index non clusterisés.
4. Étant donné que vous ne pouvez créer qu'un seul index clusterisé, dans le cas où vous avez besoin de plusieurs index, utilisez des index non clusterisés. Toutefois, si l'espace disque est un problème majeur, limitez au minimum le nombre d'index non clusterisés.

Autres considérations

Bien qu'il s'agisse des cinq éléments les plus importants de la conception d'un index de base de données, ils ne sont pas tout. Il est important de spécifier l'ordre correct des colonnes dans les index. En règle générale, les colonnes utilisées pour la prise de décision dans les clauses WHERE et les conditions telles que supérieur à (>), inférieur à (<) etc. doivent être placées avant les colonnes non impliquées dans ces clauses. Dans le cas de plusieurs colonnes dans la clause WHERE, les noms de colonne les plus distinctifs doivent être mentionnés en premier dans la définition de l'index.

Outre la conception d'index de base de données, la conception de requêtes joue également un rôle important dans l'utilisation efficace de la conception d'index. Pour une maintenance optimisée de l'index au lieu d'écrire plusieurs requêtes qui fonctionnent sur un petit nombre de lignes, essayez d'écrire moins de requêtes qui affectent un plus grand nombre de lignes de table.

Conclusion

Cet article explique certaines des principales considérations qu'un développeur de base de données doit prendre en compte lors de la conception d'index de base de données. L'article explique également la raison d'être de ces considérations et contient d'autres suggestions pour vous assurer que la conception de votre index de base de données est efficace.