Quand un index (dans un SGBD) est-il un mauvais index?

Question

Quelqu'un peut-il me dire quand un index est un mauvais index?

Answer 1

Si le champ n'est jamais utilisé, c'est un mauvais index (si vous sentez que les choses sont inutiles).

Answer 2

Si la colonne indexée n'est jamais recherchée et que la table est fortement mise à jour, vous n'obtenez pas les avantages des performances indeces. Au contraire, vous pourriez souffrir de la performance.

Answer 3

L'index est pour nous aider à rechercher les lignes plus rapidement.

Si la colonne d'index est non utilisée pour les recherches, il est inutile de la définir.

Si les valeurs de cette colonne continuer à changer très souvent, il sera un travail supplémentaire pour le serveur de base de données (pour réindexation)

S'il y a trop d'insertions et suppressions de la table Ce sera un travail supplémentaire pour le serveur

Answer 4

Une circonstance dans laquelle un index est à peu près inconditionnellement mauvais est s'il y a un autre index qui utilise les mêmes colonnes (dans le même ordre) comme préfixe:

CREATE INDEX ix_good ON SomeTable(Col1, Col2, Col3); 
CREATE INDEX ix_bad ON SomeTable(Col1, Col2); 

Le mauvais indice est un gaspillage d'espace disque et ralentit les opérations à modifier vers le bas aucun avantage.

Answer 5

Je suis lié à avant, et je lui associerez à nouveau, car il est excellent:

SQL Indexing in 9 Minutes and a Half, by Stephane Faroult.

Answer 6

Il y a une perte de performance inhérente d'avoir des indices (création et le maintien de la structure). Vous voulez généralement que ce hit bénéficie des analyses plus rapides. Quand vous n'obtenez pas le bénéfice, c'est juste une perte nette et c'est un mauvais indice.

raisons possibles:

• index Jamais utilisés
• indexe redondants
• tableaux qui ne sont pas scannés très souvent, mais mis à jour en permanence (le coup d'avoir l'indice devient trop les avantages, car la table est rarement scanné).
• Tables fréquemment analysées et mises à jour en continu. Dans ce cas, vous pouvez obtenir les avantages d'un index et d'une mise à jour/insertion dynamique en ayant une table sans index pour les insertions/mises à jour et une table avec des index pour les analyses mises à jour quotidiennement ou à chaque heure (dans certains cas Ne travaillez pas, bien sûr, et vous aurez besoin d'un meilleur matériel ou d'une nouvelle conception de l'application si vous rencontrez un sérieux problème de performances dans ce cas).

Comment trouver vos mauvais index? La plupart des SGBDR ont des options pour afficher le plan de requête, vous pouvez voir si les index que vous avez configurés sont utilisés comme vous le souhaitez. Cela m'amène à un dernier conseil, pensez à vos index, n'en créez jamais un "juste au cas où".

Answer 7

Un index est mauvais si vous ne le recherchez jamais.Par exemple, un index (Col1, Col2, Col3) est une perte de ressources si vous ne recherchez jamais avec Col1, Col2 et Col3 dans la même requête.

Answer 8

Une chose importante à garder à l'esprit avec les index (en dehors de la partie «utilisation réelle» mentionnée ci-dessus) est la notion de sélectivité. Lors de la construction d'index, vous voulez créer des index sur des colonnes qui ont une bonne chance de "haute sélectivité". Cela nécessite une certaine compréhension des données de la colonne (que vous pouvez ou ne pouvez pas avoir en fonction de votre connaissance du domaine/disponibilité des données d'échantillon).

Sélectivité = Nombre de valeurs Distinct/Nombre total de lignes

permet d'utiliser une table « People » avec des colonnes pour given_name, Nom, Sexe, Âge

Par exemple, la création d'un index sur une colonne telle comme Gender (où le genre est contraint à NULL, M ou F) ne fournirait pas beaucoup d'avantages lors d'une requête (surtout si la requête aboutit déjà à une analyse de table pour d'autres raisons). Dans n'importe quel scénario, la sélectivité de cet indice serait extrêmement faible. Selon le SGBD, l'utilisation de cet index peut être pire qu'une analyse de table complète. Toutefois, la création d'un index composite sur (Given_name, Surname) apporterait des avantages lors de l'exécution de requêtes sur ces colonnes. La sélectivité de cet indice (pour la plupart des populations) serait plutôt bonne.

Un index avec une sélectivité de 1 est l'idéal, mais la seule façon d'atteindre une sélectivité de 1 est d'avoir un index unique sur une colonne non nullable. De plus, gardez à l'esprit que vous pouvez facilement écrire des requêtes pour "garder une trace" de vos index et de leur sélectivité.