Sous-requête vs jointure interne dans le serveur SQL
J'ai des requêtes suivantes
Premier utilisant une jointure interne
SELECT item_ID,item_Code,item_Name
FROM [Pharmacy].[tblitemHdr] I
INNER JOIN EMR.tblFavourites F ON I.item_ID=F.itemID
WHERE F.doctorID = @doctorId AND F.favType = 'I'
deuxième utilisant une sous-requête comme
SELECT item_ID,item_Code,item_Name from [Pharmacy].[tblitemHdr]
WHERE item_ID IN
(SELECT itemID FROM EMR.tblFavourites
WHERE doctorID = @doctorId AND favType = 'I'
)
Dans cet article table [Pharmacy].[tblitemHdr] Contient 15 colonnes et 2000 enregistrements. Et [Pharmacy].[tblitemHdr] contient 5 colonnes et environ 100 enregistrements. dans ce scénario which query gives me better performance?
Les jointures fonctionneront généralement plus rapidement que les requêtes internes, mais en réalité, cela dépendra du plan d'exécution généré par SQL Server. Quelle que soit la façon dont vous écrivez votre requête, SQL Server la transformera toujours sur un plan d'exécution. S'il est suffisamment "intelligent" pour générer le même plan à partir des deux requêtes, vous obtiendrez le même résultat.
Dans Sql Server Management Studio, vous pouvez activer "Statistiques client" et également Inclure le plan d'exécution réel. Cela vous donnera la possibilité de connaître précisément le temps d'exécution et la charge de chaque demande.
De plus, entre chaque demande, nettoyez le cache pour éviter les effets secondaires du cache sur les performances
USE <YOURDATABASENAME>;
GO
CHECKPOINT;
GO
DBCC DROPCLEANBUFFERS;
GO
Je pense qu'il vaut toujours mieux voir de nos propres yeux que de s'appuyer sur la théorie!
Sous-requête Vs Join
Tableau un 20 rangs, 2 cols
Tableau deux 20 rangées, 2 cols
sous-requête 20 * 20
rejoindre 20 * 2
logique, rectifier
Détaillé
Le nombre de scans indique un effet de multiplication car le système devra répéter encore et encore pour récupérer les données, pour votre mesure de performance, il suffit de regarder l'heure
la jointure est plus rapide que la sous-requête.
la sous-requête permet d'accéder au disque occupé, pensez à l'aiguille de lecture-écriture du disque dur (tête?) qui va et vient quand il accède: User, SearchExpression, PageSize, DrilldownPageSize, User, SearchExpression, PageSize, DrilldownPageSize, User ... et ainsi de suite sur.
join fonctionne en concentrant l'opération sur le résultat des deux premières tables, toute jointure ultérieure concentrera la jointure sur le résultat en mémoire (ou mis en cache sur le disque) des premières tables jointes, etc. moins de mouvement d'aiguille en lecture-écriture, donc plus rapide
Source: ici
La première requête est meilleure que la deuxième requête .. parce que la première requête, nous joignons les deux tables. et vérifiez également le plan d'explication pour les deux requêtes ...
Tout dépend des données et du mappage relationnel entre les tables. Si les règles du SGBDR ne sont pas suivies, même la première requête sera lente à exécuter et à récupérer les données.