2010-09-03 10 views
0

J'écris l'application en C#. J'utilise des tables temporaires dans la transaction. Mon serveur est sql 2005. Y at-il une menace de performance, j'ai lu quelque part que l'utilisation de tables temporaires à l'intérieur des transactions devrait être évitée (http://www.sql-server-performance.com/tips/temp_table_tuning_p1.aspx poste au bas de l'écran ajouté au 24-24-2003).Tables et transactions temporaires en SQL 2005

+0

Pouvez-vous donner un exemple des opérations que vous effectuez et qui nécessitent des tables temporaires? Personnellement, je ne peux pas imaginer pourquoi vous les utiliseriez quand vous pouvez stocker des choses en mémoire dans C# –

+0

J'ai la liste des ID et je veux utiliser cette liste pour filtrer les résultats de l'instruction select. J'ai mis cette liste dans la table temporaire et dans la partie où je filtre – Darqer

+1

c'est ce que nous faisons aussi. passez une liste de Guids, placez-la dans une table temporaire et filtrez les instructions sql dynamiques (en sp) avec exists. Aucune menace de performance trouvée dans notre application. Fonctionne avec des teasend de rangées. Mais nous n'utilisons pas de transactions car nous n'acceptons que des tables temporaires pour nos pages de présentation. Nous utilisons les tables temporaires pour les mécanismes de filtrage complexes des données hiérarchiques. – Khh

Répondre

2

Ceci est assez facile à tester.

Dans une fenêtre de requête exécuter le

BEGIN TRAN 

CREATE TABLE #T1(I INT) 
INSERT INTO #T1 VALUES (1) 

suivant puis dans une autre fenêtre de requête exécuter le même. Vous constaterez qu'il n'y a pas de blocage.

Donc, la demande dans ce conseil que

il empêcherait les autres d'exécuter la même requête, blesser grandement et la performance concurrency. En effet, cela transforme votre application en une application mono-utilisateur.

semble faux.

+0

Je l'ai également vérifié dans mon application, semble fonctionner pour de nombreux utilisateurs en même temps – Darqer

0

La réponse est dans la première rangée: "En général, les tables temporaires doivent être évitées, si possible." Regardez votre application si elle est assez rapide. Essayez d'éviter une conception basée uniquement sur les tables temporaires. L'utilisation de tables temporaires doit être une exception à l'intérieur d'une application et non d'une règle. Essayez de trouver une conception alternative sans augmenter le coût (temps passé à construire le nouveau design).
Regardez cet article pour voir comment la performance est influencée par la quantité de données: http://www.sql-server-performance.com/articles/per/temp_tables_vs_variables_p1.aspx

+0

Il n'est pas possible d'éviter, dans un effort raisonnable – Darqer

+1

Pour SQL 2005 avec DB créé en 2005 (pas en mode compatible), je ne vois aucune raison de blocage. L'article est pour 2000. L'architecture a changé, et la performance ne peut pas être mauvaise seulement parce que vous utilisez une table temporaire. J'utilise (ne pas abuser) et la performance est bonne (le serveur a plus de 50 bases de données). – dragos55

Questions connexes