qui est plus rapide pour des millions d'enregistrements: table permanente ou tables temporaires?
Je dois l'utiliser que 15 millions d'enregistrements. Une fois le traitement terminé, nous supprimons ces enregistrements.
7 Réponses :
La table permanente est plus rapide si la structure de la table doit être à 100% la même chose car il n'y a pas de frais générale pour l'affectation d'espace et la construction de la table.
Table Temps est plus rapide dans certains cas (par exemple, lorsque vous n'avez pas besoin d'index présents sur une table permanente qui ralentirait les inserts / mises à jour)
Les tables Temps sont en mémoire (sauf si elles sont trop grandes), donc en théorie, ils devraient être vraiment rapides. Mais ce n'est généralement pas. En règle générale, essayez de rester à l'écart des tables TEMP, à moins que ce soit la seule solution. Pouvez-vous nous donner plus d'informations sur ce que vous essayez de faire? Il pourrait probablement être fait avec une requête dérivée
Les variables Temp stockées sont stockées dans la mémoire, pas des tables Temps.
Je n'ai pas vu la question est pour MSSQL. Dans MySQL, vous pouvez déclarer une table de mémoire temporaire: Créer un moteur de test de table temporaire = mémoire
Les variables de table sont apparemment aussi stockées dans TEMPDB - voir dba.stackexchange.com/questions/16385/...
La table permanente est plus rapide dans la plupart des cas que la table Temp.
regarder sur: http: //www.sql- server-performance.com/articles/per/derived_temp_tables_p1.aspx
Dans votre situation, nous utilisons une table permanente appelée table d'avion. Ceci est une méthode courante avec les grandes importations. En fait, nous utilisons généralement deux tableaux de transfert, un avec les données brutes et une avec les données nettoyées qui effectuent des problèmes de recherche avec le flux plus faciles (ils sont presque toujours les façons neuves et variées de nos clients pour nous envoyer des données indésirables, mais Nous devons être capables de prouver que). De plus, vous éviterez des problèmes tels que vous devez avoir à développer TEMP DB ou à causer des problèmes pour les autres utilisateurs qui souhaitent utiliser Temp DB mais doivent attendre pendant que cela augmente pour vous, etc.
Vous pouvez également utiliser SSIS et ignorer la (les) table (s) de mise de page (s), mais je trouve la capacité de revenir en arrière et de rechercher sans avoir à recharger une table de 50 000 000 est très utile.
SSIS est probablement la meilleure solution
+1 pour souligner l'avantage supplémentaire de voir les données mises en scène en cas d'erreur - "Vous pouvez également utiliser SSIS et ignorer la (les) table (s) de stockage (s), mais je trouve la capacité de revenir en arrière sans avoir à recharger Une table de 50 000 000 est très utile. "
J'utiliserai personnellement une table permanente et tronquerait-le avant chaque utilisation. Dans mon expérience, il est plus facile de comprendre / de maintenir. Cependant, mon meilleur conseil pour vous est d'essayer les deux et de voir lequel fonctionne mieux.
Cela ne fonctionnera que si le processus est un singleton et qu'il n'ya aucune chance d'un autre processus de départ entre-temps et nécessitant é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 car plusieurs processus pourraient être en cours d'exécution en même temps.
Vous pouvez résoudre ce problème en utilisant une table permuté avec une colonne unique pour identifier le processus d'importation fonctionnant avec un ensemble de données particulier. Nous avons ceux-ci pour les importations basées sur des fichiers axées sur l'utilisateur (par opposition à un lot nocturne où Truncate fonctionne bien). Pourrait envisager un processus de nettoyage pour conserver la taille de la table dans la vérification.
Si vous n'utilisez pas TEMPDB, assurez-vous que le modèle de récupération de la base de données que vous travaillez n'est pas défini sur "complet". Cela entraînera beaucoup de frais généraux sur ces inserts de rangée de 50 m de rangée.
Idéalement, vous devez utiliser une base de données de mise en scène, un modèle de récupération simple, sur RAID 10 si possible, et la taille de l'avant le temps pour fournir suffisamment d'espace pour toutes vos opérations. Tourner automatiquement éteint.
Insertion ... avec (napperon) pour éviter la journalisation de niveau de ligne: de même pour insert en vrac. Si vous déposez et recréez, créez votre index clustered antérieur pour insérer. Si vous ne pouvez pas, insérez d'une table en une seule table, puis insérez-la dans une autre table avec le bon clustering et tronquez la première table. Évitez les petites tailles de lots sur une insertion en vrac si possible. Lisez la documentation d'insertion en vrac de près, car vous pouvez saboter des performances avec les mauvaises options. Évitez l'insertion ... EXEC. Chaque ligne est enregistrée. Évitez les mises à jour, sauf si vous devez calculer les totaux de fonctionnement. Généralement, il est moins cher d'insérer d'une table dans une autre, puis de tronquer la première table que de mettre à jour en place. L'exécution des calculs totaux est l'exception, car ils peuvent être effectués avec une mise à jour et des variables pour accumuler des valeurs entre les lignes. Évitez les variables de table pour quoi que ce soit, à l'exception des structures de contrôle, car elles empêchent la parallélisation. Ne rejoignez pas votre table de rangée de 50 m à une variable de table, utilisez une table Temp à la place. N'ayez pas peur des curseurs pour l'itération. Utilisez des variables de curseur et déclarez-les avec le mot clé statique contre les colonnes à faible cardinalité à l'avant de l'index en cluster. Utilisez ceci pour couper les gros tables dans des morceaux plus gérables. N'essayez pas de faire trop dans une déclaration d'une seule déclaration.
Réponse très agréable et satisfaisante. Merci pour tout
Cela dépend.
Les tables Temps sont stockées dans la base de données TEMPDB , qui peut ou non être sur un lecteur différent de votre base de données réelle. Donc, beaucoup dépend d'a) la vitesse de ces lecteurs et b) quelles bases de données / fichiers sont sur le même lecteur. Si vous utilisez une solution de disponibilité comme la mise en miroir de la base de données, les tables Temps sont probablement plus rapides: Donc, si vous insérez 15 millions d'enregistrements dans une table, traitez-les (impliquant probablement quelques grandes mises à jour sur toutes les personnes) et supprimez-les ensuite, SQL Server doit propager tous ces changements immédiatement sur la réseau sur le serveur de miroir.
D'autre part, ce faisant dans une table temporaire restera local sur le serveur, dans la base de données
(par exemple, votre base de données réelle sera plus rapide si les fichiers de base de données et les fichiers journaux sont sur différents lecteurs physiques)
Au travail, nous utilisons une mise en miroir de base de données synchrone, ce qui signifie que si nous écrivons dans notre base de données, les données sont immédiatement écrites sur le serveur de miroir aussi bien , et le serveur principal attend la confirmation du miroir avant retourner à l'appelant (!).
TEMPDB .
Cela dépend fortement de la situation. Qu est ce que tu veux faire avec?
Table permanente. Vous vous connectez au serveur et le million d'enregistrements est déjà là, aucune action requise, sous-nano-deuxième fois! ... Peut-être que vous souciez d'élaborer sur votre question?
Je dois traiter 50 millions d'enregistrements. Pour cela, je dois créer une table permanente / temp. Le scénario est: pour approfondir 50 millions d'enregistrements, j'en crée un autre? /? table et insérer dans cette table. Ensuite, j'applique la priorité comme (fname) et insérez-le dans une autre table permanente \ Temp et supprimez de la première table. et appliquer la priorité 2, puis une première étape à nouveau. J'ai donc demandé à cette qustion. Répondez, s'il vous plaît.