166 votes

L'ordre des clauses where compte-t-il dans SQL?

Disons que j'ai une table nommée PEOPLE d'avoir 3 colonnes ID, LastName, FirstName, aucun de ces colonnes sont indexées.
LastName n'est plus unique, et FirstName est moins unique.

Si je fais 2 recherches:

select * from PEOPLE where FirstName="F" and LastName="L" 
select * from PEOPLE where LastName="L" and FirstName="F"

Ma conviction est que le deuxième est plus rapide car plus l'unique critère (LastName) vient en premier dans l' where de la clause, et les enregistrements seront supprimées de manière plus efficace. Je ne pense pas que l'optimiseur est assez intelligent pour optimiser la première sql.

Est ma compréhension correcte?

134voto

marc_s Points 321990

Non, cet ordre n'a pas d'importance (ou au moins: ne compte pas).

Tout bon optimiseur de requête look à toutes les parties de l' WHERE de la clause et de comprendre la manière la plus efficace pour satisfaire cette requête.

Je sais que l'optimiseur de requête SQL Server va choisir un adapté index - peu importe l'ordre dans lequel vous avez vos deux conditions. Je suppose que d'autres SGBDR aura des stratégies similaires.

Ce qui importe est de savoir si ou non vous avez un index adéquat pour cette!

Dans le cas de SQL Server, il est probable que l'utilisation d'un index si vous avez:

  • un index sur (LastName, FirstName)
  • un index sur (FirstName, LastName)
  • un indice sur (LastName), ou juste (FirstName) (ou les deux)

Sur l'autre main à nouveau pour SQL Server si vous utilisez SELECT * à saisir toutes les colonnes d'une table, et la table est plutôt petit, puis il ya une bonne chance que l'optimiseur de requête il suffit de faire une table (ou l'index cluster) de balayage, au lieu d'utiliser un indice (parce que la recherche dans l'ensemble des données de la page pour obtenir toutes les autres colonnes est juste trop cher très rapidement).

26voto

Gordon Linoff Points 213350

L'ordre des clauses where ne devrait pas faire une différence dans une base de données qui est conforme à la norme SQL. L'ordre d'évaluation n'est pas garanti dans la plupart des bases de données.

Ne pensez pas que SQL se soucie de l'ordre. Le texte suivant génère une erreur dans SQL Server:

select *
from INFORMATION_SCHEMA.TABLES
where ISNUMERIC(table_name) = 1 and CAST(table_name as int) <> 0

Si la première partie de cette clause ont été exécutés en premier, puis numériques seulement les noms de table se présente sous la forme d'entiers. Cependant, il échoue, fournissant un exemple clair que SQL Server (comme avec d'autres bases de données) ne se soucie pas de l'ordre des clauses dans la déclaration.

11voto

03Usr Points 1510

ANSI SQL Projet de 2003 5WD-01-Cadre-2003-09.pdf

6.3.3.3 Règle de l'ordre d'évaluation

...

D'où la priorité n'est pas déterminé par les Formats ou par des parenthèses, l'évaluation efficace des expressions est généralement effectuée à partir de la gauche vers la droite. Cependant, il est dépendant de l'implémentation de savoir si les expressions sont évalués de gauche à droite, en particulier lorsque les opérandes des opérateurs ou pourrait causer des conditions pour être soulevé ou si les résultats des expressions peut être déterminé sans complètement l'évaluation de toutes les parties de l'expression.

copié à partir d' ici

4voto

ZNK - M Points 2437

Non, tous les RDBM commencent d'abord par analyser la requête et l'optimisent en réorganisant votre clause where.

Selon le RDBM que vous utilisez, vous pouvez afficher le résultat de l’analyse (par exemple, recherchez le plan Explication dans Oracle).

M.

0voto

Chris Points 3010

En plus de ce que vous avez dit, cela dépend davantage de l'indexation des colonnes

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X