Utiliser Union au lieu de OU

Parfois, les requêtes lentes peuvent être corrigées en modifiant légèrement la requête. Un tel exemple peut être illustré lorsque plusieurs valeurs sont comparées dans une clause WHERE à l'aide de l'opérateur OR ou IN. Souvent, un OU peut provoquer une analyse d'index ou de table, qui peut ne pas être le plan d'exécution préféré en termes de consommation d'E / S ou de vitesse globale de requête.

De nombreuses variables entrent en jeu lorsque l'optimiseur de requêtes crée un plan d'exécution. Ces variables comprennent de nombreuses caractéristiques matérielles, les paramètres d'instance, les paramètres de base de données, les statistiques (table, index, auto-généré), ainsi qu'un moyen d'écrire une requête. Ici, nous changeons la façon dont nous écrivons la demande. Peu importe à quel point cela peut paraître inattendu, même si deux requêtes différentes peuvent renvoyer les mêmes résultats, le chemin qu'elles suivent peut être complètement différent selon le format de la requête.

UNION vs OR

Pour la plupart de mon expérience avec SQL Server, OR est généralement moins efficace que UNION. Ce qui se produit généralement avec OR, c'est qu'il provoque souvent une analyse. Cela peut parfois être le meilleur moyen pour certains cas, et je le laisserai comme un article séparé, mais en général, j'ai constaté que lorsqu'un grand nombre d'entrées sont affectées, c'est la principale raison de la lenteur. Commençons donc notre comparaison.

Voici notre instruction OR:

SELECT SalesOrderID, * FROM sales.SalesOrderDetail WHERE ProductID = 750 OR ProductID = 953 

À partir de ce plan d'exécution, nous voyons que nous analysons 121 000 lignes. (Vous ne pouvez pas voir le nombre de lignes, mais c'est le cas).

Maintenant, nous exécutons la même requête, mais écrite en utilisant UNION au lieu de OR:

 SELECT [SalesOrderID], * FROM sales.SalesOrderDetail WHERE ProductID = 750 UNION SELECT [SalesOrderID], * FROM sales.SalesOrderDetail WHERE ProductID = 953 

Nous voyons ici deux branches d'opérations. Une branche affecte 358 lignes et les 346 autres lignes. Les deux branches effectuent une opération de concaténation qui combine les deux ensembles de résultats. Nous avons deux recherches distinctes, mais nous avons également une recherche de clé pour obtenir la liste SELECT requise. Cela n'était pas nécessaire pour l'opération de numérisation, car nous avons toujours affecté toutes les lignes de l'opération de numérisation, de sorte que les données ont été obtenues pendant l'analyse, pas après. Cela est dû à l'index et aux lignes dont nous avons besoin, pas à UNION ou OR. Cependant, je dirai que la sélection est également un facteur dans le choix d'une recherche par rapport à l'analyse, mais nous l'ignorerons dans cet article.

Explication

Pourquoi UNION provoque plus de recherches au lieu d'analyses, car chaque opération doit satisfaire à une certaine exigence de sélectivité afin de se qualifier pour une recherche. (La sélectivité est l'unicité d'une colonne filtrée particulière). OU se produit en une seule opération, donc lorsque la sélectivité pour chaque colonne est combinée et dépasse un certain pourcentage, le balayage est alors considéré comme plus efficace.

Étant donné qu'UNION effectue une opération distincte pour chaque opérateur par défaut, la sélectivité de chaque colonne n'est pas combinée, ce qui lui donne une meilleure chance d'effectuer une recherche. Maintenant, comme UNION effectue deux opérations, ils doivent faire correspondre leurs jeux de résultats à l'aide de l'opération de concaténation décrite ci-dessus. Ce n'est généralement pas une opération coûteuse.

Il convient également de noter que la clause OR fonctionne de la même manière que l'instruction IN.

J'espère que cette astuce vous aidera. Je crois que cela est très précieux lorsque vous travaillez avec des systèmes qui nécessitent une concurrence élevée.