Meilleure utilisation des indices sur les tables temporaires en T-SQL

Question

Si vous êtes en train de créer une table temporaire à l'intérieur d'une procédure stockée et vous souhaitez ajouter un indice ou deux sur elle, pour améliorer les performances de toutes les autres déclarations faites à son encontre, ce qui est la meilleure approche?Sybase dit cette:

"le tableau doit contenir des données lors de la création de l'index.Si vous créez la table temporaire et de créer l'index sur une table vide, Adaptive Server ne crée pas de colonne de statistiques tels que les histogrammes et les densités.Si vous insérez des lignes de données après la création de l'index, l'optimiseur a des statistiques incomplètes."

mais récemment, un collègue a mentionné que si je créer la table temporaire et les indices dans une autre procédure stockée à celui qui utilise la table temporaire, puis Adaptive Server de l'optimiseur va être en mesure de faire usage d'entre eux.

Dans l'ensemble, je ne suis pas un grand fan de wrapper procédures qui apportent peu de valeur, donc je n'ai pas réellement eu le temps de tester, mais j'ai pensé que j'avais posé la question là-bas, pour voir si quelqu'un a d'autres approches ou des conseils?

Answer 1

Quelques réflexions:

• Si votre table temporaire est si grand que vous avez de l'indice, alors est-il une meilleure façon de résoudre le problème?

• Vous pouvez le forcer à utiliser l'index (si vous êtes sûr que l'index est la bonne façon d'accéder à la table) en donnant un optimiseur de soupçon, de la forme:

  SELECT * 
  FROM   #table (index idIndex) 
  WHERE  id = @id
  

Si vous êtes intéressé par la performance des conseils en général, j'ai répondu à une couple d'autres questions à ce sujet en détail ici:

• Favorite de réglage des performances de trucs
• Comment optimisez-vous les tables pour des requêtes spécifiques?

Answer 2

Quel est le problème avec l'ajout de l'index après avoir insérer des données dans la table temporaire?

Une chose que vous devez être conscient de, c'est la visibilité de l'indice aux autres instances de la procédure qui pourrait être en cours d'exécution en même temps.

Je tiens à ajouter un guid pour ces types de tables temporaires (et de l'index), assurez-vous qu'il n'est jamais un conflit.L'autre avantage de cette approche est que vous pouvez tout simplement faire le temp table une table réelle.

Aussi, assurez-vous que vous aurez besoin pour interroger les données de ces tables temporaires plus d'une fois lors de l'exécution de la procédure stockée, sinon le coût de la création de l'index l'emportent sur les avantages pour la sélectionner.

Answer 3

Dans Sybase si vous créez une table temp et ensuite l'utiliser dans un proc le plan de la sélection est construit en utilisant une estimation de 100 lignes dans la table.(Le plan est construit lors de la procédure commence avant que les tables sont remplies.) Cela peut entraîner la temp table table numérisée depuis qu'il est seulement "100 lignes".L'appel d'une autre proc causes Sybase pour construire le plan pour le sélectionner avec le nombre réel de lignes, ce qui permet à l'optimiseur de choisir un meilleur indice à utiliser.J'ai vu d'importantes improvedments à l'aide de cette approche, mais de le tester sur votre base de données que parfois il n'y a pas de différence.