J'ai une question d'optimisation de la requête.
Pour le contexte, cette requête a toujours fonctionné instantanément
mais aujourd'hui, il a fallu beaucoup plus de temps. (3h +)
J'ai donc essayé de le réparer.
La requête est comme -> quand je rejoint maintenant les deux parties avec l'intérieur, la requête devient incroyablement longue. Alors je l'optimisez à l'aide d'union à la place ou ou existe au lieu de
Mais il faut toujours 3 minutes Je veux l'obtenir de nouveau à 5 secondes. Voyez-vous un problème de requête? Merci
3 Réponses :
Votre code est confus mais pour la première partie
Vous pouvez essayer d'utiliser une Union sélectionnée pour la sous-requête intérieure (celles-ci avec ou)
et évitez la clause dans l'utilisation d'une jointure interne
Utiliser aussi, si possible, modifiez ci-dessous Joindre à Union et existe à gauche Join.
Merci de votre réponse, mais comme je l'ai déjà dit: je l'optimisa à l'aide de l'union au lieu de ou et existe au lieu de cela, mais il faut toujours 3 minutes. Je vais essayer la jointure gauche!
Mes excuses! Dans la partie 2 de la requête à la fois des deux tables faisant référence à la même colonne Colseekedina. Alors pourquoi deux questions sont créées?
L'approche existante peut donner des résultats parasites car vous obtiendrez des lignes qui ne correspondent pas à une condition seulement si une ligne correspond à 1 rangée. Cela pourrait être évité par l'utilisation d'existence dans une sous-requête corrélée, mais ce n'est pas quelque chose que j'ai expérimenté suffisamment pour recommander.
Pour la vitesse, je vais passer à une croix s'appliquer et spécifier la table des parents dans l'expression de croix Appliquer (corrélation sous-requête pour créer une table dérivée). De cette façon, la condition de jointure est spécifiée avant que les données ne soient renvoyées, si les colonnes en question ont des index sur eux (c'est-à-dire qu'ils sont des touches primaires), l'optimisateur peut élaborer un plan efficace pour cela. P>
Union tout est utilisé dans l'expression de la croix s'appliquant comme cela empêche un tri distinct dans la table dérivée qui est généralement plus lourde en termes de coût que de rapporter les données lui-même (Union doit identifier toutes les lignes de toute façon, y compris les duplications). P>
Enfin, si cela est toujours lent, vous voudrez peut-être ajouter un index à la colonne Date du tableau A. Ceci surmonte l'absence de sargabilabilité inhérente à une colonne de date et signifie que l'optimisateur peut exploiter l'index plutôt que de numériser toutes les lignes de la série de résultats et tester si la date est égale aujourd'hui. P>
Select someCols from A
inner join B left join C
cross apply (Select Z.colseekedinA from tab Z where a.col=z.colseekedinA
union all
Select X.colseekedinA from tab X where a.col=x.colseekedina) d
Where A.date = Today
Le seul problème est que votre requête peut retourner des doublons si X et Z renvoient la même valeur.
Vous pouvez utiliser une clause distincte sur la requête extérieure, cela triera le nombre minimum de lignes car le filtrage aura déjà eu lieu au moment où le distinct est appelé.
Vous avez 3 questions dans votre extrait, pas une. Votre question est vague, car elle se trouve.
Qu'est-ce que
ou - union signifie? Où est la clause pour leou? a.date = aujourd'hui `n'est pas une syntaxe valide non plus.aujourd'hui n'est pas un mot clé T-SQL (sauf siaujourd'hui est une colonne dansA ,b ou < Code> C , auquel cas il devrait être aliasé).Poster le plan d'explication. Va nous aider à analyser mieux
Outre les points larnu fabriqués, toutes vos questions avec des jointures sont syntaxiquement incorrectes, car vous manquez le
sur bit des jointures.De plus, si la requête était rapide avant, qu'est-ce qui a changé?
@AMN Oui ... La partie 1 et la partie 2 sont les deux parties de la requête ... Prendre chaque seconde mais quand je les rejoins avec le col de la partie 1 dans le col de la partie 2
S'il vous plaît voir Collez le plan pour un moyen d'inclure un plan d'exécution dans votre question.