Indexation d'une base de données

Je ne connais pas très bien les bases de données et maintenant j'essaie de comprendre le mécanisme d'indexation.

D'après ce que je sais, dans un SGBDR, l'indexation sur une colonne rend la recherche par cette colonne plus rapide. Cela est également vrai pour les magasins triples, seuls les indices supposent que vous rechercherez (par exemple) principalement par sujet, puis par objet, etc.

Je ne suis pas sûr du SGBDR, mais sur les magasins triples, vous pouvez définir plus d'un index, laissant le magasin choisir le meilleur index pour chaque requête (j'espère avoir bien compris). Naturellement, la question suivante apparaît:

Pourquoi ne devrais-je pas ajouter tous les index possibles à un triple magasin et étendre à un SGBDR, pourquoi ne pas créer des index sur chaque colonne (en supposant que je ne suis pas trop paresseux)?

Parce que, essentiellement, un index est une table supplémentaire, où la clé primaire est le champ que vous indexez et le seul contenu est la clé primaire de votre table principale. Ainsi, chaque mise à jour doit être répliquée dans chaque index qui utilise le champ que vous mettez à jour.

Cela est particulièrement visible sur les inserts. Imaginez si chaque insertion effectuée sur une table devait être répliquée sur 20 autres tables. Ça va être douloureusement lent.

Notez que cela devient encore pire avec les index composés, clusterisés et en texte intégral, mais je ne veux pas encore compliquer le problème pour vous.

Les index sont essentiellement des structures de données supplémentaires qui doivent être construites et stockées. Construire indé gaspille de l'énergie CPU (pendant les opérations d'écriture) et le stocker gaspille la capacité du disque.

Pourquoi voudriez-vous construire et stocker des index que vous n'utilisez jamais?

Ne placez les index qu'en cas de besoin. En règle générale, lorsque je développe un schéma de base de données, chaque table obtient un index cluster clé primaire PK pour commencer. Ce sera l'identifiant unique pour les données de cette table. Dans peut être sur 1 colonne ou plusieurs.

Après cela, j'ajoute généralement des index uniques non clusterisés sur les colonnes sur lesquelles je veux renforcer l'unicité.

Ceci est le schéma de base. À mesure que l'application se développe et mûrit, nous ajoutons des index selon les besoins, en fonction des problèmes de performances et de la façon dont nous interrogeons les données.

Chaque index ajouté augmente l'espacement utilisé et ajoute un entretien supplémentaire. Choisissez donc judicieusement vos index.

La force des index est qu'ils sont 1) une structure de données qui peut être recherchée rapidement et 2) plus compacts que les tables réelles, permettant à une plus grande partie de l'index de tenir dans la mémoire au lieu d'être paginée sur le disque.

Si vous avez un index sur chaque colonne, les index eux-mêmes prendront plus d'espace que la table qu'ils représentent. Si la base de données utilise vraiment tous les index, il faudra plus de temps pour les échanger dans et hors de la mémoire. De plus, chaque index doit être mis à jour lors d'une inertie, d'une mise à jour ou d'une suppression.

Au-delà de cela, les index sur une seule colonne ne sont même pas les meilleurs que vous puissiez faire. La plupart des bases de données de relations autorisent en fait un index sur plusieurs colonnes, et l'ordre de ces colonnes est important. Par exemple, si je veux rechercher dans une base de données toutes les personnes qui sont allées à Duke entre 1980 et 1984, alors ce que je veux, c'est un index (School, ClassYear). La requête ne pourrait pas utiliser un index avec les mêmes colonnes, mais inversée.

Donc pour créer tous les index possibles, il y a au moins n! façons d'organiser les colonnes dans un index. Avec seulement 5 colonnes, il existe 120 index possibles.

Puisqu'il y a tellement d'index possibles, vous devez vraiment déterminer quels index sont utiles pour votre application et en créer uniquement.

La création d'un index pour chaque colonne d'une table est généralement une perte d'espace et, comme d'autres l'ont mentionné, cela peut ralentir les opérations d'insertion / mise à jour. Un index est utilisé pour accélérer les requêtes. Je ne recommanderais d'ajouter un index à une colonne que si vous constatez des performances médiocres lors de la recherche de valeurs dans cette colonne.

Certaines bases de données peuvent nécessiter un index pour la clé primaire d'une table, vous n'aurez donc peut-être pas le choix. De plus, si vous avez de très grandes colonnes de texte, il existe des technologies spécifiques conçues pour la recherche et l'indexation en texte intégral, mais ce ne sont pas toujours les mêmes types d'index que vous utiliseriez pour une petite colonne numérique.