Aller au contenu

optimisation requête toute simple


Sujets conseillés

Posté

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.

  • 3 semaines plus tard...
Posté (modifié)

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é par Prélude
Posté
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

Posté
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.

Posté

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.

Posté

Salut,

Une idée en passant.... :whistling:

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.

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...