optimisation requête toute simple

[davidc1]

Bonjour,

J'ai une requête qui doit aller acceder à 25 éléments d'une table, la voici :

SELECT * FROM osc WHERE BHSELLER=2 LIMIT ###,25

le soucis c'est que le ### est assez important (plusieurs centaine de milliers)

- BHSELLER est bien évidemment indexé, c'est un INT.

- la table fait pour le moment moins d'1 million d'entrées et cette requête prend environ 0.6 secondes à être traitée.

Comment l'optimiser pour qu'elle soit plus rapide ?

merci par avance,

David.

[Prélude]

Bonjour,

Elle est on ne peut plus simple cette requête. Difficile de l'optimiser directement.

Hormis changer le "*" par la liste des colonnes dont tu as réellement besoin...

Après quoi, c'est de l'optimisation au niveau du serveur (MyIsam / Inodb, mysql_fetch_row ...)

Modifié 17 Janvier 2007 par Prélude

[loban]

Bonjour,

J'ai une requête qui doit aller acceder à 25 éléments d'une table, la voici :

SELECT * FROM osc WHERE BHSELLER=2 LIMIT ###,25

le soucis c'est que le ### est assez important (plusieurs centaine de milliers)

- BHSELLER est bien évidemment indexé, c'est un INT.

- la table fait pour le moment moins d'1 million d'entrées et cette requête prend environ 0.6 secondes à être traitée.

Comment l'optimiser pour qu'elle soit plus rapide ?

merci par avance,

David.

Si je comprends bien, ton SGBD est obligé de se reconstituer un index de plusieurs centaines de milliers de clé à chaque fois.

Tu gagnerais à utiliser un deuxième champs dont le contenu varie comme un timestamp.

Ensuite, en fournissant le timestamp à chaque fois, ta requête deviendrait :

SELECT * FROM osc WHERE BHSELLER=2 AND TIMESTAMP > xxx LIMIT 0,25

[davidc1]

changer le "*" par la liste des colonnes dont tu as réellement besoin

je ne peux pas, j'ai besoin de toute la table, dommage.

Pour la solution de loban, j'ai compris :

ajouter un 2ème champ, de type compteur INT par exemple, qui est unique et s'incrémente pour chaque élément avec un BHSELLER identique. La différence qui s'en suivra sera que le xxx de la requête sera bien inférieur à mon ###.

Est ce que c'est ça ?

david.

[loban]

Oui, c'est cela. (j'ai oublié une clause ORDER BY dans mes explications).

Au final, tu remplaces le système de 'LIMIT n,25' par une exploitation des données d'une TABLE et de son INDEX.

[adn]

Salut,

Une idée en passant....

Une table de type HEAP te permettrait-elle pas de meilleures perfos. Reste ensuite à mettre en place la création de celle-ci et sa sauvegarde.