Dites par exemple, je rejoint sur une table numérique pour effectuer une certaine opération entre deux dates de sous-requête, comme:
select n
,(select avg(col1)
from table1
where timestamp between dateadd(minute, 15*n, @ArbitraryDate)
and dateadd(minute, 15*(n+1), @ArbitraryDate))
from numbers
where n < 1200
6 Réponses :
Daadd sera de mieux performer que la contaténation de chaîne et la coulée sur DateTime.
comme toujours, vous seriez meilleur parier pour profiler les 2 options et déterminer le meilleur résultat, car aucun dB n'est spécifié.
Soyez prudent avec entre et dates, jetez un coup d'œil à Comment fonctionne entre les dates de SQL Server?
J'ai une fois optimisé une requête pour fonctionner de plus de 24 heures à 36 secondes. Il suffit d'utiliser des fonctions de date ou des conversions sur la colonne, voyez ici: uniquement dans une base de données Vous pouvez obtenir 1000% + amélioration en modifiant quelques lignes de code
Pour voir quelle requête fonctionne mieux, exécutez les deux requêtes et examinez les plans d'exécution, vous pouvez également utiliser des statistiques IO et le temps de statistiques pour obtenir le nombre de lectures et le temps qu'il a fallu pour exécuter les requêtes
Merci pour la tête sur "entre". Je vois que je me chevaucherais.
Le entre traite votre gamme en tant que Plage fermée , lorsque la pratique standard consiste à utiliser des gammes semi-ouvertes. Par exemple, [a, b) signifie faire a <= x il est donc très pratique d'écrire des choses comme "au cours de l'année 2019" comme [2019 , 2020) et pour le traduire en SQL comme @x> = '2019-01-01' et @x <'2020-01-01' , contre devoir souffrir de < Un href = "https://stackoverflow.com/questions/21825615"> Epsilons spécifiques de type de données @x entre "2019-01-01" et '2019-12-31 23:59 : 59.997 , pour éviter d'inclure 2020-01-01 00:00 .
Tant que vos calculs de prédicat n'incluent pas les références aux colonnes de la table que vous avez interrogée, votre approche ne devrait pas avoir d'importance de toute façon (aller clarifier).
Si vous deviez inclure quelque chose à partir de Dans tous les cas, vérifiez (ou post!) Le Exécution plan pour confirmer. Table1 dans le calcul, je ferais cependant attention aux analyses de table ou à la couverture des analyses d'index car il ne peut plus être sargable .
Pourquoi utiliseriez-vous une sous-requête corrélée pour commencer? Cela va vous ralentir beaucoup plus que datadd. Ce sont comme des curseurs, ils travaillent en rangée à la rangée.
Est-ce que quelque chose comme ça fonctionne?
C'est une bonne idée. Le problème est que la table1 n'est pas énumérée (ni nécessairement énumérable).
J'ai remplacé la jointure intérieure avec la sortie extérieure gauche, de sorte que cette requête soit équivalente à celle d'origine.
En général, il est clair que les sous-requêtes corrélées fonctionnent à la ligne de rangée. Nous pouvons comparer des plans d'exécution et voir pour nous-mêmes.
Alex une citation directe des livres en ligne: "Dans les requêtes qui incluent une sous-requête corrélée (également appelée sous-requête répétée), la sous-requête dépend de la requête extérieure pour ses valeurs. Cela signifie que la sous-requête est exécutée à plusieurs reprises, une fois pour chaque ligne qui peut être sélectionné par la requête extérieure. "
@Hlgem et @Alexkuznetsov, je ne pense toujours pas que cela fonctionnera à moins que Table1 ne soit énorme. Le tableau1 nécessiterait une colonne N sur laquelle rejoindre.
HLGEM, la citation des livres en ligne est tout simplement fausse. Je vais casser ce mythe sur sqlblog.com dans quelques minutes.
Très probablement, il n'y aura pas de différend à une manière ou une autre.
Je voudrais courir ceci: suivi des deux variantes de votre requête, de sorte que vous voyiez et comparez les coûts d'exécution réels.
Garder les données dans le format DateTime à l'aide de daadd est le plus susceptible d'être plus rapide
Vérifiez cette question: moyen le plus efficace Dans SQL Server pour obtenir la date à partir de la date + l'heure?
La réponse acceptée (pas moi!) Démontre des conversions de rubrique sur les chaînes. J'en ai vu un autre il y a trop d'années qui montrait le même
C'est exactement le type de réponse que j'espérais. +1 à vous pour le trouver et +1 à Tomas pour la grande référence. Merci!
n est un domaine Int (ou Smallint, peu importe) dans le tableau1?
@Patrick Karcher, N est une INT de la table [numéro].
Peut-être avez-vous besoin de nous montrer la structure de la table1