Discussion :

[clavier12AZQSWX]

bonjour,

hier soir en parlant avec un anglo-saxon de problèmes de rapidité d'une base de données pas si énorme que ça, il me faisait réviser les principes d'optimisations d'une requêtes SQL dans son écriture pure (donc en considérant la bonne pause des index déjà).

Et là, cette personne m'a sorti de son chapeau anglais une règle que je découvre après 20 ans de SQL sur 4 SGBD (mais pour moi aucune expérience en MS sql server contrairement à lui).

Il m'a appris (ou plutôt m'a dit) que l'ordre de déclaration des éléments dans la clause WHERE devait se faire suivant l'ordre de création des indexs dans la base de données.

Par exemple, si on fait "WHERE a=1 and B=2 and c=3" on a intérêt à ne pas avoir posé l'index A en dernier dans la construction de la base sinon la requête sera plus lente ! cela me paraît être une contrainte technique (voir un défaut) du sgbd plus qu'une règle mais bon...

Moi ça me paraît surtout être une aberration cette règle, mais comme je ne connais pas MS sql server, peut-être que c'est vrai dans ce sgbd là et pas dans d'autres (postgres, mysql par exemple)

qu'en pensez-vous ?
je lui ai demandé des explications, je les aurai dans la soirée.

J'en profite pour remettre à jour mes connaissances. Alors corrigez moi !

Il y a 10 ans en licence info, on nous apprenait que dans une clause WHERE il fallait mettre en premier les conditions qui évacuent le plus de tuples .

Par exemple, dans "where a=1 and b=2 and c=3" il faut impérativement que la condition la plus à gauche "a=1" déliste le plus possible de possibilités de recherche au sgbd et ainsi que la condition la plus à droite (c=3) sert juste au final à affiner la recherche dans ce qui reste.

vrai ou pas encore aujourd'hui ? dans tous les sgbd ?

Ensuite on nous a appris l'inverse (en bac+5), ou plutôt un bémol. ça dépend de si on fait des conditions avec des = ou avec des <>.
Ainsi si on a 'where a<>1 and b<>2 and c<>3", alors il faut que "a<>1" rassemble le moins de tuples possibles .

vrai ou pas ce second principe de bac+5 ! ?

Ensuite est venu l'expérience du métier où j'ai volontairement oublié certaines de ces règles car suivant les sgbd on se rend compte que (en tout cas moi) :

"where a=1 and b=1 and c=1 " est plus long que "where c=1 and b=1 and a=1 " si le champ le plus à gauche possède un type plus complexe que le champ à droite et ce, quel que soit la charge de tuples évacuée.

Par exemple, à gauche il vaut mieux mettre les conditions avec des champs de type INT ou de type BOOLEAN et mettre au plus à droite les conditions avec des champs de type fulltext.

alors en 2012, qu'est-ce qui est encore vrai de toutes ces choses ?

[tatayo]

Bonjour,
De ce que j'ai noté avec MaxDB, non seulement l'ordre des critères dans la clause Where n'a strictement aucune influence sur le plan d'execution, mais il en est de même de l'ordre des jointures.
Ce qui compte vraiment c'est l'ordre des colonnes dans les clé composées, mais uniquement lors de la définition de ces clés.

Pour t'en convraincre, le plus simple est de passer par un Explain sur une requête.

tatayo.

[Bluedeep]

Et là, cette personne m'a sorti de son chapeau anglais une règle que je découvre après 20 ans de SQL sur 4 SGBD (mais pour moi aucune expérience en MS sql server contrairement à lui).

Il m'a appris (ou plutôt m'a dit) que l'ordre de déclaration des éléments dans la clause WHERE devait se faire suivant l'ordre de création des indexs dans la base de données.

Ben, il doit pas avoir des masses d'expérience avec Sql Server pour sortir un truc pareil. C'est faux. Les optimiseurs sont capables de gérer cela depuis ... belle lurette. D'ailleurs, en controlant les plans d'exécution, on s'aperçoit que cela ne change strictement rien.

[SQLpro]

On voit vraiment se diffuser des conneries gigantesques ! A part MySQL qui n'a pas d'optimiseur digne de ce nom, aucun des grands SGBDR C/S ne traite les clause dans l'ordre d'écriture, ni même d'ailleurs n’exécute les différentes partie du SQL tel que vous l'avez écrit.

Dans mon cours à Orsys sur l'optimisation de MS SQL Server je montre du doigt ce genre de choses. Voici le cas en pratique :
http://blog.developpez.com/sqlpro/p5...lle-intellige/

Vous verrez dans cet exemple reproductible sur Oracle ou SQL Server que le serveur récrit intégralement la requête pour satisfaire la demande initiale et donc les critères qu'il y ait index ou pas, sont ordonnées d'abord dans le sens d'une exécution logique puis dans le sens du plus discriminant au moins discriminant (les statistiques sont là pour ça).

Il n'y a guère que PostGreSQL et MySQL qui ne savent pas faire ce genre de requête !!!

Dans la 4e édition de mon livre sur SQL, voici ce que je dit dans un nouveau chapitre sur l'indexation :

"

Exemple 1 – création d’un index multi colonne :
CREATE INDEX X_PRS_NOM_PRE_DTN
ON T_PERSONNE_PRS (PRS_NOM, PRS_PRENOM, PRS_DATE_NAISSANCE DESC);
[...]
Le parcours de l’index par recherche ne peut se faire que dans le sens de vectorisation de
l’information :
· nom
· nom suivi de prénom
· nom suivi de prénom suivi de date de naissance
Les autres recherches sont médiocres car il faut lire toutes les données de l’index par
balayage.
L’ordre des colonnes dans le prédicat de recherche n’a pas d’importance pour l’égalité, car
l’optimiseur du SGBDR recombine les colonnes afin d’utiliser correctement l’index. Mais ce
n’est pas toujours possible, notamment lorsque le prédicat utilise des opérateurs d’inégalité.
Ainsi dans le cas d’un prédicat tel que :
WHERE PRS_PRENOM BETWEEN 'Jean' AND 'Jeannot' AND PRS_NOM = 'DUPONT'
L’index sera pleinement utilisé (recherche) car l’optimiseur recombine les différentes parties
du prédicat pour utiliser au mieux l’indexl’index, tandis que dans le cas de ce prédicat :
WHERE PRS_NOM BETWEEN 'DUPOND' AND 'DUPONT' AND PRS_PRENOM = 'Jean'
Il le sera moins (recherche + balayage), et qu’avec le suivant :
WHERE PRS_PRENOM = 'Jean' AND PRS_NOM > 'DUPON'
Ou plus aucune recherche dans l’index n’est possible et il faudra pour le moins balayer tout
l’index
"

A noter d'ailleurs que PostGreSQL ne sait toujours pas faire de SCAN d'index....

A +

[Rei Ichido]

Au vu d'une discussion récente sur le forum Oracle, précisons quand même que certains SGBD (Oracle au moins !) laissent des modes de compatibilité avec d'anciens modes de fonctionnements (pour Oracle : OPTIMIZER_MODE = RULE). Il est bien sûr plus que fortement déconseillé de les utiliser ...
Cela revient à utiliser un SGBD récent en lui précisant de se comporter comme une version vieille de 20 ans, mais à ce qui ressort de la discussion en question, certains systèmes continuent à le faire.

[SQLpro]

Vous avez le même hint pour SQL Server : FORCEORDER... Ce qui est effectivement une aberration... Mais il existe encore des gens utilisant des bases 6.5 !!!

A +