J'ai deux requêtes que je suis UNION ensemble de telle sorte que je sais déjà qu'il n'y aura pas d'éléments en double entre les deux requêtes. Par conséquent, UNION et UNION ALL produiront les mêmes résultats.Pour union ou union tout, c'est la question
Lequel dois-je utiliser?
Vous devriez utiliser celui qui correspond à l'intention de ce que vous cherchez. Si vous voulez vous assurer qu'il n'y a pas de doublons, utilisez UNION, sinon utilisez UNION ALL. Juste parce que vos données produiront les mêmes résultats dès maintenant ne veut pas dire que ça le sera toujours. Cela dit, UNION ALL sera plus rapide sur n'importe quelle implémentation saine de base de données, voir les articles ci-dessous pour des exemples. Mais généralement, ils sont les mêmes, sauf que UNION effectue une étape supplémentaire pour supprimer des lignes identiques (comme on pourrait s'y attendre), et il peut avoir tendance à dominer le temps d'exécution.
J'utiliser UNION ALL de toute façon. Même si sait qu'il n'y aura pas de doublons, selon le moteur de votre serveur de base de données, il peut ne pas le savoir. Donc, juste pour fournir des informations supplémentaires au serveur DB, pour que son planificateur de requêtes soit un meilleur choix (probablement), utilisez UNION ALL.
Cela dit, si votre planificateur de requêtes de base de données serveur est assez intelligent pour en déduire que les informations des devraient être les mêmes, puis les résultats (performance et sémantique sage) et clause UNION index tableau.
Dans les deux cas, cela dépend fortement du serveur de base de données que vous utilisez.
Selon http://blog.sqlauthority.com/2007/03/10/sql-server-union-vs-union-all-which-is-better-for-performance/ au moins pour la performance, il est préférable d'utiliser UNION ALL, car il ne doublons pas activement distinctes et en tant que tel est plus rapide
Je vois que vous avez balisé cette performance question, donc je suppose que ce votre principale considération.
UNION ALL va absolument surpasser UNION puisque SQL n'a pas besoin de vérifier les deux ensembles pour les dups.
Sauf si vous avez besoin de SQL pour effectuer la vérification des doublons, utilisez toujours UNION ALL.
Je pense qu'il le sait déjà. Il demande spécifiquement dans le scénario qu'il sait (et DB sait probablement aussi) qu'il n'y aura pas de dups. –
Je ne comprends pas votre point. Demandez-vous, "si SQL peut déterminer qu'il n'y aura jamais de chevauchement dans les deux ensembles, va-t-il optimiser le 'UNION' afin qu'il n'ait pas à comparer, ce qui le rendrait identique à 'UNION ALL'? utilisez 'UNION ALL' – BradC
Puisqu'il n'y aura pas de doublons des deux utiliser UNION ALL. Vous n'avez pas besoin de vérifier les doublons et UNION ALL effectuera la tâche plus efficacement.
Voulez-vous du sirop avec cette gaufre? –
Étant donné que les données proviennent de deux tables non liées qui contiennent des GUID, je sais qu'il n'y aura jamais de contenu en double entre les deux requêtes. –
@Mark - Ce n'est pas déroutant, c'est répondre à deux saveurs de la question. La question principale est: "Lequel dois-je utiliser?" et la réponse est "utilisez celle qui correspond à votre intention". La question * implicite * est "laquelle serait la plus rapide à utiliser?", Et la réponse est "UNION ALL" –