Nous rencontrons des problèmes de performances à l'aide d'une variable de table dans une procédure stockée.
Voici ce qui arrive réellement: p> La sélection renvoie 138 résultats, mais insère dans La variable de table prend 1min15 mais lorsque j'utilise une table Temp avec le même SELECT, WOOPS, prend 0sec: P> CREATE TABLE #temp (iId_company INT)
INSERT INTO #temp(iId_company)
SELECT id FROM ...
4 Réponses :
Utilisez une table temporaire. Vous verrez beaucoup de meilleures performances.
Une explication détaillée du raisonnement derrière cela dépasse la portée de l'initiale question cependant à résumer:
Google Table Table vs. variable de table pour une mine de ressources et de discussions. Si vous avez alors besoin d'une assistance spécifique, choisissez-moi un email ou contactez-moi sur Twitter.
Généralement, pour des ensembles de données plus petits, une variable de table doit être plus rapide qu'une table TEMP. Pour des ensembles de données plus importants, les performances diminueront car les variables de table ne prennent pas en charge le parallélisme (voir cet article ).
Avec cela dit, je n'ai pas expérimenté ou trouvé une expérience avec un tel ensemble de données plus lent pour une variable de table VS une table Temp.
Pas que cela devrait importer mais que ressemble votre choix? J'ai eu un problème dans SQL Server 2005 où mon choix sur ses propres manières était relativement rapide pour ce que ma requête faisait 5 minutes pour rendre toutes les données sur le fil d'environ 150 000 rangées. Mais lorsque j'ai essayé d'insérer le même choix dans une table Temp ou une variable de table, l'instruction a couru pendant plus d'une heure avant que je sache. Je dois encore comprendre ce qui se passait vraiment. J'ai fini par ajouter la commande de force d'indice de requête et cela a commencé à insérer plus vite.
Point clé sur les tables Temps est également que vous pouvez mettre des index, etc. sur eux, tandis que vous ne pouvez pas avec les variables de table.