Discussion :

[barok]

Bonjour tout le monde.
Une question que je me pose depuis longtemps.
Considérons une table avec un id comme clé primaire en auto incrémente et 3 champs : champ1 et champ2 (VARCHAR on va dire) et date (type date).

1) Si je souhaite faire un select, qu'est-ce qui est le plus rapide

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * from table where id = '65'

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * from table where id = '65' AND champ1 = 'sdfsdf' AND champ2 = 'fghfghfg'

en supposant que les champs contiennent "sdfsdf" et "fghfghfg"

2) Autre chose
Maintenant je fais ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT * from table where id = '65' 
AND 'tres gros calcul de conversion sur le champ date'

Comment mysql va optimiser cela, va-t-il d'abord regarder s'il trouve l'id 65 puis faire le gros calcul ou bien faire plusieurs fois le gros calcul jusqu'a ce qu'il tombe sur l'id 65.

3) Dans le précédent cas, id était unique (car auto-incrémenté). Si ce n'était pas le cas genre on le retrouve une dizaine de fois dans une table de 100000 entrées mais que le champ est indexé, le calcul de date ne se ferait que sur les 10 lignes ramenées ou sur d'autre lignes pendant la recherche.

J'espère que vous avez compris ce que je souhaitais dire (mais non je ne vous prends pas pour des cons ). Je vous remercie.

[Swoög]

normalement MySQL évalue d'abord les propriétés les moins couteuses...

ensuite, il vaut mieux s'en assuré via l'ordre d'indication (d'abord les moins couteux)...

pour être sûr de tout ça, il faudrait tout de même consulter la doc sur l'optimisation : http://dev.mysql.com/doc/refman/4.1/...imization.html

[barok]

C'est ce que je me dit donc je mets les condition sur la clé primaire en 1er, puis les index puis les calculs les plus gros à la fin.
Si quelqu'un pouvait me confirmer cela.

[Sivrît]

http://dev.mysql.com/doc/refman/4.1/...mizations.html

Je pense que l'on peut compter à ce que les champs indexés (surtout s'ils ont des valeurs uniques, comme une clef primaire) soient traités en premier.
Donc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * from table where id = '65' AND champ1 = 'sdfsdf' AND champ2 = 'fghfghfg'

sera plus lent que la version sans les égalités, mais si id est une clef cela ne fera jamais que deux comparaisons effectuées sur la ligne retournée (bref rien).

Après pour la complexité des différents tests d'un where... Je suppose que pour les simples égalités les choses sont claires mais après...

3) Dans le précédent cas, id était unique (car auto-incrémenté). Si ce n'était pas le cas genre on le retrouve une dizaine de fois dans une table de 100000 entrées mais que le champ est indexé, le calcul de date ne se ferait que sur les 10 lignes ramenées ou sur d'autre lignes pendant la recherche.

D'après la doc sans problème. C'est les index d'abord, et ceux qui éliminent le plus en premier. Pour passer à côté il faut une table très petite ou un index qui ne sert à rien (donc pas du 10 pour 100000) :
http://dev.mysql.com/doc/refman/4.1/...able-scan.html
(y'a même FORCE INDEX pour les paranoïaques que nous sommes)