Lesquelles ont de meilleures performances: Tables dérivées ou tables temporaires

Question

Parfois, nous pouvons écrire une requête avec une table dérivée et une table temporaire. Ma question est celle qui est la meilleure? Pourquoi?

Answer 1

La table dérivée est une construction logique.

Il peut être stocké dans le tempdb, créé au moment de l'exécution en réévaluant l'instruction sous-jacente chaque fois qu'on y accède, ou même en l'optimisant.

La table temporaire est une construction physique. C'est une table en tempdb qui est créée et remplie avec les valeurs.

Lequel est le mieux dépend de la requête dans laquelle ils sont utilisés, de l'instruction utilisée pour dériver une table et de nombreux autres facteurs.

Par exemple, CTE (expressions de table communes) dans SQL Server peut (et sera probablement) réévalué chaque fois qu'ils sont utilisés. Cette requête:

WITH q (uuid) AS 
     (
     SELECT NEWID() 
     ) 
SELECT * 
FROM q 
UNION ALL 
SELECT * 
FROM q 

sera très probablement rendement deux « s NEWID() différents.

Dans ce cas, une table temporaire doit être utilisée car elle garantit que ses valeurs persistent.

D'autre part, cette requête:

SELECT * 
FROM (
     SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn 
     FROM master 
     ) q 
WHERE rn BETWEEN 80 AND 100 

est mieux avec une table dérivée, car l'aide d'une table temporaire, il faudra aller chercher toutes les valeurs de master, alors que cette solution suffit de scanner les premiers 100 enregistrements à l'aide l'index sur id.

Answer 2

Cela dépend des circonstances.

Avantages des tables dérivées:

1. une table dérivée fait partie d'un plus grand, seule requête, et sera optimisée dans le contexte du reste de la requête. Cela peut être un avantage si l'optimisation de la requête aide les performances (ce qui est généralement le cas, à quelques exceptions près). Exemple: si vous remplissez une table temporaire, puis consommez les résultats dans une deuxième requête, vous liez le moteur de base de données à une méthode d'exécution (exécutez la première requête dans son intégralité, enregistrez le résultat entier, exécutez la deuxième requête) Avec une table dérivée, l'optimiseur pourrait trouver une méthode d'exécution ou un chemin d'accès plus rapide. Une table dérivée seulement "existe" en termes de plan d'exécution de la requête - c'est purement une construction logique. Il n'y a vraiment pas de table.

Avantages des tables temporaires

1. Le tableau « existe » - qui est, il est matérialisé comme une table, au moins dans la mémoire, qui contient le jeu de résultats et peut être réutilisé.Dans certains cas, les performances peuvent être améliorées ou le blocage réduit lorsque vous devez effectuer une transformation élaborée sur les données. Par exemple, si vous souhaitez extraire un ensemble de lignes 'snapshot' d'une table de base qui est occupé, puis faire un calcul compliqué sur cet ensemble, il peut y avoir moins de contention si vous obtenez les lignes hors de la table de base et déverrouillez-le aussi rapidement que possible, puis faites le travail de façon indépendante. Dans certains cas, le surcoût d'une table temporaire réelle est faible par rapport à l'avantage de la simultanéité.

Answer 3

La grande différence est que vous pouvez mettre des contraintes, y compris une clé primaire sur une table temporaire. Pour les grands (je veux dire des millions de disques), vous pouvez parfois obtenir de meilleures performances avec temporaire. J'ai la requête clé qui a besoin de 5 jointures (chaque joint se trouve être similaire). Les performances étaient correctes avec 2 jointures, puis la troisième performance a mal tourné et le plan de requête est devenu fou. Même avec des conseils, je ne pouvais pas corriger le plan de requête. Essayé de restructurer les jointures en tant que tables dérivées et toujours les mêmes problèmes de performance. Avec les tables temporaires, vous pouvez créer une clé primaire (puis quand je remplis le premier tri sur PK). Lorsque SQL pourrait rejoindre les 5 tables et utiliser les performances PK est passé de quelques minutes à quelques secondes. Je souhaite que SQL supporte les contraintes sur les tables dérivées et CTE (même si seulement un PK).

Answer 4

Je veux ajouter une anecdote ici car elle m'amène à conseiller le contraire de la réponse acceptée. Je suis d'accord avec la pensée présentée dans la réponse acceptée mais c'est surtout théorique. Mon expérience m'a amené à recommander des tables temporaires sur des tables dérivées, des expressions de tables communes et des fonctions de valeur de table. Nous avons largement utilisé des tables dérivées et des expressions de tables communes avec beaucoup de succès en fonction de réflexions cohérentes avec la réponse acceptée jusqu'à ce que nous commencions à traiter des ensembles de résultats plus importants et/ou des requêtes plus complexes. Nous avons ensuite constaté que l'optimiseur n'opérait pas bien avec la table dérivée ou CTE.

J'ai regardé un exemple aujourd'hui qui a duré 10h15. J'ai inséré les résultats de la table dérivée dans une table temporaire et joint la table temporaire dans la requête principale et le temps total a chuté à 0:03. Habituellement, lorsque nous voyons un gros problème de performance, nous pouvons rapidement l'aborder de cette façon. Pour cette raison, je recommande les tables temporaires à moins que votre requête ne soit relativement simple et que vous soyez certain qu'elle ne traitera pas de grands ensembles de données.