Discussion :

[DadaWeb]

Bonjour,

Je cherche à optimiser une requete SELECT (mono table) en ajoutant des index sur les colonnes utilisées lors de la recherche.

MySQL utilise bien ces index lorsque le nombre de lignes en réponse à la requete est peu important, par contre si la requête renvoie un nombre plus important (6056 pour mon exemple) il ne les utilise plus...

Voici la requete : EXPLAIN SELECT * FROM nomtable WHERE col1 ='valeur num (1 à 8)' AND col2 ='Oui ou Non'

Les col1 et col2 sont indexées. Voir ci-dessous le résultat de requêtes avec 2 valeurs différentes dans la colonne1 : le premier cas étant le résultat avec beaucoup de lignes

table type possible_keys key key_len ref rows
nomtable ALL index1, index2 null null null 6056
nomtable ref index1, index2 index2 3 const 1

J'avoue que je sèche un peu !!!!!
Si quelqu'un à un élément de réponse, merci d'avance

[Maximil ian]

Bonjour,

Peut-on avoir une idée de la fréquence des différentes valeurs des colonnes col1 et col2 (combien de pourcentage de lignes avec col1=1, 2, 3 ... 8, et col2='Oui' ou 'Non') ?

L'optimiseur doit estimer que les index ne seront pas utiles vu la forte proportion d'une certaine valeur dans col1 (et pareil avec col2 vu que cette colonne ne peut prendre que 2 valeurs) et faire un full table scan.

Essaie peut-être avec un index double sur (col1, col2)...

[selecta]

Tu dois effectivement analyser les cardinalités des champs indexés qui composent ta clause WHERE pour comprendre sur quelles valeurs il décide ou non d'utiliser l'index

Code :

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

1
2
 
select col1, count(*) from nomtable group by 1

[DadaWeb]

Merci pour ta réponse. C'est sans doute l'optimiseur qui estime que les index ne sont pas utiles.

Pour info sur la première colonne une des valeurs (5) représente à elle seule 99.18% des enregistrements.
Pour la 2ème colonne le (non) représente 98.8 % des enregistrements.

J'ai essayé avec un index double et c'est idem. Peut être qu'en augmentant la memoire côté serveur ? Car dans l'état actuel la reqête prend 28 seconde en moy ce qui est assez pénalisant...

Merci

[pcaboche]

Car dans l'état actuel la reqête prend 28 seconde en moy ce qui est assez pénalisant...

Comment t'arrives à faire pour avoir une requête qui met 28 secondes à s'exécuter alors que c'est juste un SELECT * FROM table WHERE ... et que tu n'as "que" 6056 enregistrements? Tu nous caches des choses !

Si c'est pour de l'affichage seulement, tu as pensé à la clause LIMIT ?

[DadaWeb]

Ah pourtant je cache rien j'vous jure !!!! Du moins à ma connaissance...

En fait je n'utilise pas la clause LIMIT, car j'ai besoin d'afficher toutes les données sous la forme d'un formulaire par enregistrement pour un nouveau traitement.

C'est une sorte de corbeille et bien sûr la longueur de la page html varie en fonction du nombre de dossiers dans la corbeille...

[Maximil ian]

Pour info sur la première colonne une des valeurs (5) représente à elle seule 99.18% des enregistrements.
Pour la 2ème colonne le (non) représente 98.8 % des enregistrements.

Avec une telle répartition tu ne tireras malheureusement rien des index, à part précisément pour accéder aux 0,9 % de lignes qui se distinguent de la masse...

Si tu es à la recherche de performances il faudrait effectuer des réglages sur les différentes variables serveur (cache de requêtes, etc.) à condition que tu y ais accès bien sûr.
Selon le contexte applicatif il pourrait aussi être bon de diviser cette grosse page Web en plusieurs plus petites, en utilisant LIMIT justement...

[DadaWeb]

Oui, je vais voir côté serveur.

Merci à tous pour vos réponses.