Une requête WHERE fera-t-elle des vérifications sur des comparaisons plus simples (c'est-à-dire bit) avant d'exécuter des comparaisons plus ardues (c'est-à-dire varchar)?

12

Si j'écris une requête qui inclut une WHEREclause composée , par exemple:

SELECT *
FROM MyTable
WHERE BitField = 1
    AND VarcharField = 'asdf'

et l'inclusion de cette bitcomparaison exclut simplement les mêmes champs que la varcharcomparaison exclura, la présence de cette bitcomparaison de champs me rendra-t-elle une amélioration des performances?

sql-server optimization

— andrewb
source

22

Il est important de reconnaître que SQL est un langage déclaratif. La SELECTrequête que vous avez écrite spécifie les résultats logiques à renvoyer. C'est au moteur de base de données, en particulier à l'optimiseur de requêtes, de déterminer une stratégie physique efficace pour renvoyer ces résultats.

Le plan d'exécution physique final dépendra des capacités de raisonnement de l'optimiseur, du temps qu'il est prêt à consacrer au problème, de la disponibilité de méthodes d'accès appropriées (principalement des index et des vues matérialisées), des informations statistiques représentatives et le chemin de code particulier que votre la spécification de la requête passe par le code d'optimisation.

En général, si la conception de votre base de données est relationnelle, vous fournissez de bonnes méthodes d'accès et des informations statistiques précises, et la requête est bien écrite, l'optimiseur trouvera normalement une stratégie d'exécution physique raisonnable sans que vous ayez à vous soucier trop de la forme écrite de trop la spécification de la requête.

Il y aura toujours des cas où l'expression de la même exigence logique en utilisant une syntaxe différente (mais sémantiquement identique) affectera le plan d'exécution physique, mais cela devrait être une préoccupation secondaire. Encore une fois, généralement, envisagez d'exprimer la requête différemment si les caractéristiques d'exécution ne sont pas acceptables, une fois que toutes les bases mentionnées ci-dessus ont été couvertes.

Il serait rare à l'extrême que l'ordre écrit des WHEREprédicats de clauses conjonctives simples (comme dans la question) affecte le plan d'exécution physique de manière mesurable. En bref, ce n'est pas quelque chose dont vous devriez vous soucier. Obtenez d'abord la conception de la base de données, les index et les informations statistiques.

Pour répondre directement à la question (éventuellement!), L'ajout de la condition redondante supplémentaire peut améliorer les performances, mais uniquement si elle permet d'utiliser une méthode d'accès plus efficace - par exemple, s'il n'y a qu'un index (BitField, VarcharField). S'il y avait déjà un index sur (VarcharField), il ajouterait uniquement des frais généraux.

En tant que détail d'implémentation, non, SQL Server ne prend pas en compte le coût des comparaisons en fonction du type de données ou de la complexité de calcul apparente. En fait, il y a peu de coûts précieux pour les opérations scalaires , mais cela nous amène à un tout autre sujet.

Questions connexes:

Opérateurs logiques OU ET en condition et ordre des conditions dans OERE
SQL Server 2008 et expressions constantes
Opérateurs au niveau du bit affectant les performances
Comportement des instructions SQL étranges

— Paul White 9
source

5

Les partitions binaires (comme une colonne de bits) sonnent comme de bons candidats pour les index filtrés.

CREATE NONCLUSTERED INDEX MyTableWithBitFieldTrue
ON MyTable (VarcharField)
INCLUDE Id, <other columns you're selecting>
WHERE BitField = 1 ;
GO

Être explicite sur vos optimisations signifie que votre code est plus robuste face aux modifications des autres, que ce soit dans votre base de code ou dans SQL Server.

— Greg
source