Performances des requêtes SQL
Dans ce cas particulier, vous ne remarquerez pas une énorme différence car 30 000 lignes ne sont pas trop difficiles à traiter pour la base de données. Cependant, si vous parliez de centaines de millions de lignes ou plus, vous constateriez une amélioration notable en agrégeant avant de rejoindre. Lorsque vous faites cela, assurez—vous que ce que vous faites est logiquement cohérent – vous devriez vous soucier de la précision de votre travail avant de vous soucier de la vitesse d’exécution.
13 CONSEILS SUR LES PERFORMANCES DES REQUÊTES
N’oubliez pas de préfixer les noms d’objets (i.e. table, procédure stockée, vue) avec son nom de propriétaire/schéma.
Raison: Si le nom du propriétaire / du schéma n’est pas fourni, le moteur de SQL Server essaie de le trouver dans tous les schémas jusqu’à ce que l’objet le trouve. Le moteur SQL Server ne recherchera pas la table en dehors de son propriétaire / schéma si le nom du propriétaire/ schéma est fourni.
L’opérateur *
N’utilisez pas l’opérateur * dans vos instructions SELECT. Utilisez plutôt des noms de colonnes.
Raison : SQL Server recherche tous les noms de colonnes et remplace le * par tous les noms de colonnes des tables de l’instruction SQL SELECT. La fourniture de noms de colonnes évite cette recherche et ce remplacement et améliore les performances.
Colonnes annulables
Évitez d’utiliser NOT IN lors de la comparaison avec des colonnes annulables. Use N’EXISTE PAS à la place.
Raison : Lorsque NOT IN est utilisé dans la requête (même si la requête ne renvoie pas de lignes avec les valeurs null), SQL Server vérifiera chaque résultat pour voir s’il est nul ou non. L’utilisation de NOT EXISTS ne fera pas la comparaison avec les valeurs nulles. De plus, NOT EXISTS ne renvoie que deux états (true ou false), tandis que NOT IN peut renvoyer jusqu’à trois états (true, false, NULL) et peut ne pas vous donner le résultat que vous attendiez.
Variables de table et Jointures
Évitez d’utiliser des variables de table dans les jointures. Utilisez plutôt des tables temporaires, des CTE (Expressions de table communes) ou des tables dérivées dans les jointures.
Raison: Même si les variables de table sont très rapides et efficaces dans de nombreuses situations, le moteur SQL Server les considère comme une seule ligne. Pour cette raison, SQL produira un plan d’exécution qui fonctionnera horriblement lorsqu’il sera utilisé dans les jointures.
Noms de procédure stockés
Ne commencez pas le nom de votre procédure stockée par sp_.
Raison: Lorsque la procédure stockée est nommée sp_ ou SP_, SQL Server vérifie toujours dans la base de données système / maître même si le nom du propriétaire / du schéma est fourni. Fournir un nom sans SP_ à une procédure stockée évite cette vérification inutile dans la base de données système / maître de SQL Server.
Utilisez SET NOCOUNT ON
Utilisez SET NOCOUNT ON avec des opérations DML.
Raison : Lors de l’exécution d’opérations DML (i.e. INSÉRER, SUPPRIMER, SÉLECTIONNER et METTRE À JOUR), SQL Server renvoie toujours le nombre de lignes affectées. Dans les requêtes complexes avec beaucoup de jointures, cela devient un énorme problème de performances. L’utilisation de SET NOCOUNT ON améliorera les performances car elle ne gardera pas de trace du nombre de lignes affectées.
Évitez d’utiliser GROUP BY, ORDER BY et DISTINCT
Évitez d’utiliser GROUP BY, ORDER BY et DISTINCT dans la mesure du possible.
Raison : Lorsque vous utilisez GROUP BY, ORDER BY ou DISTINCT, le moteur SQL Server crée une table de travail et place les données sur la table de travail. Après cela, il organise ces données dans la table de travail comme demandé par la requête, puis renvoie le résultat final.
Index de vérification
Il devrait y avoir des index sur tous les champs utilisés dans les parties WHERE et JOIN de l’instruction SQL.
Raison : Lorsque les champs ne sont pas indexés, SQL Server effectue généralement une analyse complète de la table, ce qui peut réduire les performances. À moins que la table ne soit très petite, une analyse de table a tendance à produire les pires performances de tous les types de lectures de base de données.
Utilisez le même type de données sur les clauses JOIN et WHERE
Cela est plus facile à dire qu’à faire en fonction de vos autorisations pour apporter des modifications au schéma.
Raison : Lorsque vous joignez ou comparez deux champs avec des types de données différents, SQL doit effectuer une conversion à la volée du champ avant de pouvoir effectuer une comparaison, même si les champs sont indexés. Si des types de données incompatibles sont inévitables, essayez de convertir le type de données le plus grand en type de données le plus petit dans la mesure du possible.
Évitez d’utiliser des champs calculés dans la JOINTURE et des clauses WHERE
Cela peut être fait en créant un champ avec les valeurs calculées utilisées dans la jointure sur la table. Voir ci-dessous.