Performances de requêtes assez étranges [Résolu]

[RR instinct]

Bonjour,

Je suis actuellement en train d'essayer d'améliorer les performances de mon logiciel qui grossit et qui commence à avoir plusieurs tables avec des milliers voir des millions de lignes...

Je constate un truc assez bizarre, et si quelqu'un pouvait m'éclairer ca serait sympa !

Donc je pose le décor :

J'ai deux tables (lieu et vehicule) qui contiennent toutes deux un index sur le champ étranger CLE_PERSONNE, et différents champs dont deux datetime pour la table véhicule et 1 timestamp pour la table lieux.

En chiffres :
lieu : 673 000 lignes.
vehicule : 2 100 000 lignes.

J'effectue deux requêtes sur chacune des tables (l'une après l'autre) sur lesquelles j'ai un clause where sur CLE_PERSONNE puis sur les champ date.

Code :

1
2
3
SELECT  /*... 12 champs ...*/
FROM vehicule
WHERE DATE_DEBUT>='2010-11-04' AND DATE_DEBUT <='2010-11-11' AND CLE_PERSONNE=105 ORDER BY DATE_DEBUT

Code :

1
2
3
SELECT /*... 7 champs ...*/
FROM lieu
WHERE DATE_CHANGE BETWEEN '2010-11-04 00:00' AND '2010-11-11 00:00' AND CLE_PERSONNE=105 ORDER BY CLE_PERSONNE, DATE_CHANGE

J'observe un temps de réponse sur l’exécution de la requête d'environ 10ms sur la table vehicule et 50 ms sur la table lieu.... ce qui n'est pas logique pour moi ! l'inverse à la rigueur mais la je comprend pas pourquoi !

J'ai fait des EXPLAIN pour voir :

vehicule

Code :

1
2
3
4
5
6
7
8
9
10
11
 
id => 1, 
select_type => 'SIMPLE', 
TABLE => 'lieu',
type => 'ref',
possible_keys => 'CLE_PERSONNE',
KEY => 'CLE_PERSONNE',
key_len => 4,
ref => 'const',
rows => 3250,
extra => 'Using where; Using filesort'

lieu

Code :

1
2
3
4
5
6
7
8
9
10
11
 
id => 1, 
select_type => 'SIMPLE', 
TABLE => 'lieu',
type => 'ref',
possible_keys => 'CLE_PERSONNE',
KEY => 'CLE_PERSONNE',
key_len => 4,
ref => 'const',
rows => 486,
extra => 'Using where; Using filesort'

Tout laisse à penser que le traitement est le même, mais alors pourquoi il met plus de temps à traiter 486 lignes plutôt que 3250 quelqu'un pourrait m'expliquer ?

J'ai pensé au fait que ce soit un timestamp et non un datetime dans la table lieu ou alors le BETWEEN (qui est à priori meilleur au niveau performance d'après ce que j'ai pu voir... mais pas la...)

[Sylv666]

Peut être l'usage de BETWEEN dans l'une et pas l'autre ?

[GyZmoO]

Pourrais-t-on voir la structure des 2 tables en question?

[RR instinct]

Bon j'aurais du essayer avant ca m'aurait pas pris longtemps mais à priori ca vient bien du between...

Code :

SELECT * FROM lieu WHERE DATE_CHANGE >= '2010-11-04 00:00' AND DATE_CHANGE <= '2010-11-11 00:00' AND CLE_PERSONNE=105 ORDER BY CLE_PERSONNE, DATE_CHANGE

Me donne des temps de réponse à peu près égaux à l'autre requête.

Désolé de vous avoir fait perdre votre temps, en tout cas c'est bon à savoir que BETWEEN ne signifie pas forcément gain de performance...