Analyse de table et ajout d'index - lequel est plus rapide?

Question

J'ai une table avec plusieurs millions de lignes. J'ai besoin de trouver toutes les lignes avec une valeur de colonne spécifique. Cette colonne n'est pas dans un index, donc un résultat d'analyse de table.

Mais serait-il plus rapide d'ajouter un index avec la colonne en tête (clé principale suivante), faire la requête, puis supprimer l'index?

Je ne peux pas ajouter un index de façon permanente car l'utilisateur nomme la colonne qu'il recherche.

Answer 1

L'ajout d'un index nécessite un balayage de table, donc si vous ne pouvez pas ajouter un index permanent, il semble qu'un seul balayage sera (légèrement) plus rapide.

Answer 2

Non, ce ne serait pas plus rapide. Ce qui serait plus rapide serait d'ajouter l'index et de le laisser là!

Bien sûr, il peut ne pas être pratique d'indexer chaque colonne, mais encore une fois il peut. Comment les données sont-elles ajoutées à la table?

Answer 3

Ce ne serait pas. Créer un index est plus complexe que de simplement scanner la colonne, même si la complexité de calcul est la même.

Cela dit - combien de colonnes avez-vous? Êtes-vous sûr de ne pas pouvoir créer un index pour chacun d'entre eux si le temps de recherche pour une recherche unique est trop long?

Answer 4

Je ne suis pas un administrateur de base de données, mais je suppose que la construction de l'index nécessiterait de balayer la table de toute façon.

À moins qu'il y ait plusieurs requêtes sur cette colonne, je recommande de ne pas créer l'index.

Il est préférable de vérifier les plans/temps d'exécution pour les deux façons.

Answer 5

Cela dépend de la complexité de votre requête. Si vous récupérez les données une seule fois, l'analyse des tables est plus rapide. Toutefois, si vous revenez plusieurs fois à la table pour obtenir des informations connexes dans la même requête, l'index est plus rapide.

Une autre stratégie connexe consiste à effectuer l'analyse de table et à placer toutes les données dans une table temporaire. Indexez ensuite THIS et vous pourrez ensuite effectuer tous vos sélections, regroupements et autant d'autres requêtes sur le sous-ensemble de données indexées. L'avantage est que la recherche d'informations connexes dans les tables liées à l'aide de la table temporaire est beaucoup plus rapide.

Cependant, l'espace est bon marché ces jours-ci, donc vous seriez probablement mieux servi en examinant comment vos utilisateurs utilisent réellement votre système et en ajoutant des index sur ces colonnes fréquentes. Je n'ai pas encore vu les utilisateurs utilisent TOUS les paramètres de recherche tout le temps.

Answer 6

Comme tout le monde l'a dit, il ne serait certainement pas plus rapide d'ajouter un index que de faire un scan complet de cette colonne.

Cependant, je suggère de suivre le modèle de requête et de trouver quelles colonnes sont les plus recherchées, et d'ajouter des index au moins pour eux. Vous pouvez découvrir que 3-4 index accélère 90% de vos requêtes.

Answer 7

Deux questions à méditer:

1. Combien de colonnes pourraient être nommés pour la requête?
2. Est-ce que les données changent fréquemment? Beaucoup?

Si vous avez un petit nombre de colonnes candidats, et les données ne change pas beaucoup, alors vous voudrez peut-être envisager d'ajouter un indice permanent sur tout ou même toutes les colonnes candidat.

"Blasphème!", j'entends. La plupart des sources vous indiquent de ne jamais indexer chaque colonne d'une table, mais cela est basé sur l'hypothèse générique que les tables sont fréquemment modifiées.

Vous paierez un prix en stockage supplémentaire, ainsi qu'un coup de performance lorsque les données changent.

Quelle est la taille petit et combien est beaucoup, et est le compromis entre la peine? Il n'y a aucun moyen de dire un prieuré parce que "trop ​​lent" est généralement une mesure subjective.

Vous devrez l'essayer, mesurer la taille de vos index, puis l'effet qu'ils ont dans les recherches. Vous devrez équilibrer les coûts avec l'augmentation de la satisfaction de vos clients.

[Ajouté] Oh, encore une chose: les index temporaires sont non seulement physiquement plus lents qu'un scan de table, mais ils détruiraient votre concurrence. La réindexation d'une table nécessite généralement (toujours?) Un verrouillage de table complet, de sorte qu'une seule recherche d'utilisateur peut être effectuée à la fois.

Bonne chance.

Answer 8

Votre solution ne sera pas mise à l'échelle sauf si vous ajoutez un index permanent à chaque colonne, avec toutes les colonnes qui sont retournées dans la requête dans la liste des colonnes incluses (un index de couverture). Ces index seront très volumineux, et les insertions et les mises à jour de cette table seront un peu plus lentes, mais vous n'avez pas beaucoup de choix si vous permettez à un utilisateur de sélectionner arbitrairement une colonne de recherche.

Combien de colonnes y a-t-il? À quelle fréquence les données sont-elles mises à jour? À quelle vitesse les insertions et les mises à jour doivent-elles être exécutées? Des compromis sont nécessaires, en fonction des réponses à ces questions. Faire beaucoup d'expérimentation et de tests afin que vous sachiez à coup sûr comment les choses vont fonctionner. Mais à votre question d'origine, l'ajout et la suppression d'un index dans le cadre d'une seule requête n'est utile que si vous en sélectionnez plusieurs lors de la requête (par exemple, le select est dans une sous-requête exécutée). pour chaque ligne retournée).