Table vs Temp les Performances de la Table

Qui est plus rapide pour des millions d'enregistrements: Table Permanente ou Tables Temp?

- Je l'utiliser que pour 15 millions d'enregistrements. Une fois le traitement terminé, on supprimer ces dossiers.

Il dépend fortement de la situation. Que voulez-vous utiliser?
Permanente de la table. Vous vous connectez au serveur et les millions d'enregistrer est déjà là, aucune action n'est requise, sous la nano-seconde de temps! ... Peut-être que vous vous souciez de vous revenir sur votre question?
j'ai pour traiter 50 millions de disques. pour cela, je dois créer Permanent/table Temp. Le scénario est le suivant: pour proecssing de 50 Millions de disques, j'ai créer un autre ?/? table et Insérez-les dans ce tableau. Puis-je appliquer priorité (Fname) et de l'insérer dans un autre Permanent\temp de table et de supprimer à partir de la première table. et appliquer la priorité 2 et la première étape à nouveau. j'ai donc demandé à cette qustion. s'il vous plaît Répondre.

OriginalL'auteur ManishKumar1980 | 2009-10-23

  1. 15

    Dans votre situation, nous utilisons une table permanente appelée une table intermédiaire. Cette méthode est couramment employée avec de grandes importations. En fait, généralement, nous utilisons les deux tableaux intermédiaire de l'un avec les données brutes et l'un avec l'nettoyé de données ce qui rend les recherches sur les problèmes avec l'alimentation la plus facile, ils sont presque toujours le résultat de formes nouvelles et variées de nos clients à trouver de nous envoyer des données inutiles, mais nous devons être en mesure de prouver qu'). En Plus de vous éviter d'avoir à croître temp db ou de causer des problèmes pour les autres utilisateurs qui veulent utiliser temp db, mais ont à attendre que ça pousse pour vous, etc.

    Vous pouvez également utiliser SSIS et passez la table intermédiaire(s), mais je trouve la capacité de revenir en arrière et de recherche sans avoir à recharger les 50 000 000 de table est très utile.

    SSIS est probablement la meilleure solution
    +1 pour souligner l'avantage de voir la mise en scène des données dans le cas d'une erreur -- "Vous pouvez également utiliser SSIS et passez la table intermédiaire(s), mais je trouve la capacité de revenir en arrière et de recherche sans avoir à recharger les 50 000 000 de table est très utile."

    OriginalL'auteur HLGEM

  2. 12

    Si vous n'utilisez pas la base de données tempdb, assurez-vous que le modèle de récupération de la base de données de travail n'est pas "Plein". Ce sera la cause de beaucoup de surcharge sur les 50M insertions de lignes.

    Idéalement, vous devriez utiliser une base de données intermédiaire, modèle de récupération simple, RAID 10, si possible, et la taille à l'avance le temps de fournir suffisamment d'espace pour toutes vos opérations. Allumer l'auto-pousser à l'extérieur.

    Utiliser INSERT ... (TABLOCK) pour éviter au niveau de la ligne d'enregistrement:

    INSERT INTO StagingTable WITH (TABLOCK) (.....)
SELECT .....

    De même pour l'instruction BULK INSERT. Si vous supprimez et recréez, créer votre index cluster avant à insérer. Si vous ne pouvez pas insérer dans une table d'abord, puis l'insérer à partir que dans une autre table avec le droit de clustering, et de tronquer la première table. Éviter les petites tailles de lots en VRAC INSÉRER si possible. Lire l'essentiel d'INSÉRER de la documentation de près, comme vous pouvez le sabotage de la performance avec les mauvaises options.

    Éviter d'INSÉRER ... EXEC. Chaque ligne est connecté.

    Éviter les Mises à jour, sauf si vous avez besoin de calculer les totaux en cours d'exécution. En général, il est moins cher à l'insertion d'un tableau dans un autre, et puis tronquer le premier tableau, que pour la mise à jour en place. L'exécution de calculs de totaux sont l'exception, car ils peuvent être fait avec une mise à JOUR et les variables d'accumuler des valeurs entre les lignes.

    Éviter les variables de table pour tout sauf pour les structures de contrôle, puisqu'ils empêchent la parallélisation. Ne joignez pas vos 50M de la ligne du tableau à une variable de table, utiliser une table temporaire à la place.

    N'ayez pas peur de les curseurs pour l'itération. Utilisez le curseur de variables, et de les déclarer avec le mot-clé STATIC en contre-bas de la cardinalité des colonnes à l'avant de l'index cluster. Utilisez cette tranche de grandes tables en plus de morceaux gérables.

    N'essayez pas d'en faire trop dans une déclaration.

    Très Agréable et Satisfoctory Réponse. Merci pour tout

    OriginalL'auteur Peter Radocchia

  3. 2

    Table permanente est plus rapide si la structure de la table est à 100% le même car il n'y a pas de frais généraux pour l'attribution de l'espace et de la construction de la table.

    De la table temporaire est plus rapide dans certains cas (par exemple, lorsque vous n'avez pas besoin d'indices qui sont présents sur la table permanente qui serait de ralentir les insertions, mises à jour)

    OriginalL'auteur DVK

  4. 0

    Table permanente est plus rapide dans la plupart des cas de la table temporaire.

    Avoir un regard sur : http://www.sql-server-performance.com/articles/per/derived_temp_tables_p1.aspx

    je ne peux pas utiliser les tables Dérivées...

    OriginalL'auteur anishMarokey

  5. 0

    Personnellement, je voudrais utiliser une table permanente et de le tronquer avant chaque utilisation. Dans mon expérience, il est plus facile à comprendre et à maintenir. Cependant, mon meilleur conseil pour vous est d'essayer les deux et voir celui qui fonctionne mieux.

    Cela fonctionnera seulement si le processus est un singleton, et il n'y a aucune chance de tout autre processus de démarrage dans le temps, et exige également l'utilisation de cette table. Nous avons des processus qui importent beaucoup de données et nous ne serions pas en mesure de tronquer une table unique parce que plusieurs processus pourrait être en cours d'exécution en même temps.
    Vous pouvez résoudre que par l'aide d'un perm table avec une colonne unique pour identifier le processus d'importation de travailler avec un ensemble de données particulier. Nous avons pour l'utilisateur du fichier de base des importations (par opposition à un tous les soirs lot où tronquer fonctionne très bien). Pourrait envisager un processus de nettoyage à garder la table de la taille.

    OriginalL'auteur Mayo

  6. 0

    Il dépend.

    Tables temporaires sont stockés dans le tempdb base de données, qui peut ou peut ne pas être sur un disque différent de celui de votre base de données réelle. Donc, cela dépend beaucoup de la a) la vitesse de ces disques et b) les bases de données/les fichiers sont sur le même disque.

    (par exemple, votre base de données sera plus rapide si les fichiers de base de données et les fichiers journaux sont sur différents disques physiques)

    Si vous utilisez une solution de disponibilité de la Base de données mise en Miroir, tables temporaires sont probablement plus rapide:

    Au travail, nous utilisons la Base de données synchrone de mise en Miroir, ce qui signifie que si nous écrire à notre base de données, les données sont immédiatement enregistrées dans le serveur miroir ainsi, et le principal serveur attend le miroir de confirmation avant de retourner à l'appelant(!).

    Donc, si vous insérez 15 millions d'enregistrements dans une table, de les traiter (impliquant probablement quelques grandes mises à jour sur tous d'entre eux) et de les supprimer par la suite, SQL Server a pour propager tous ces changements immédiatement sur le réseau vers le serveur miroir.

    Sur l'autre main, faire cela dans une table temp va rester en local sur le serveur, dans le tempdb base de données.

    OriginalL'auteur Christian Specht

  7. -1

    Tables temporaires sont dans la mémoire (sauf s'ils sont trop gros), donc, en théorie, ils devraient être très rapide.
    Mais il est généralement pas.
    En règle générale, essayez de rester loin de tables temporaires, sauf que c'est la seule solution.
    Pouvez-vous nous donner plus d'informations à propos de ce que vous essayez de faire? Il pourrait probablement être fait avec un dérivé de la requête

    Temp Variables sont stockées dans la Mémoire ne sont pas des tables temporaires.
    Je n'ai pas vu la question est de MSSQL. Dans MySQL, vous pouvez déclarer une mémoire temporaire de la table: CREATE TEMPORARY TABLE test ENGINE=MEMORY
    Les Variables de Table sont apparemment également stockées dans la base de données tempdb - voir dba.stackexchange.com/questions/16385/...

    OriginalL'auteur adamJLev