Surcharge BDD ?

[RomsIW]

Bonjour,

Je trouvais que le back office était un peu lent et j'ai fait un diagnostic à base de microtime pour savoir d'où cela venait. Il s'avère que si je mets un marqueur juste avant et juste après la requête, il m'indique plus de 6 secondes... Il ne met pas autant pour faire les autres requêtes du site. Il est vrai que cette requête-ci est particulièrement longue (référencement des 20 dernières commandes, couplées avec les tables de factures, et deux autres tables pour des informations sur les commandes.

Voici les marqueurs :

Code: Tout sélectionner

$time_start = microtime_float();
      $les_demandes = $BDD_connexion->get($req_les_demandes);
      $demandes = array();
$time_end = microtime_float();

la fonction get dans ma classe :

Code: Tout sélectionner

   function get($q){   
      $to_return = FALSE;
      if($this->link==0 && $this->host!="" && $this->username!="" && $this->dbname) $this->open($this->dbname);
      if($this->link!=0){ //echo $q."<br />";
         
         $resultset = @mysql_query($q) or print("
<h2>Une erreur SQL est survenue</h2>
<strong>Erreur N° : </strong>".mysql_errno()."
<br /><strong>Description : </strong>".mysql_error()."
<br /><strong>Host / User / DB :</strong> ".$this->host." / ".$this->username." / ".$this->dbname."
<br /><strong>Req posant problème :</strong> ".$q."
<br /><strong>Link :</strong> ".$this->link.""
);
         if($resultset){
            $this->nb_query++;
            $this->last_query = $q;
            if(mysql_num_rows($resultset)==0) $to_return = 0;
            else $to_return = $resultset;
         }
      }
      return $to_return;
   }

Temps d'exécution : 6.24645709991...

D'où cela peut-il venir ?

Merci d'avance pour votre aide.

[EDIT]J'ajoute que je viens d'imprimer ma requête et de la faire exécuter à partir de phpMyAdmin, la durée d'exé semble être la même "Affichage des enregistrements 0 - 19 (20 total, traitement: 6.4335 sec.)"[/EDIT]

[ltressens]

Ca vient de tout ce que tu nous montre pas ici :
structure de la table et requete utilisée...

[RomsIW]

Ca vient de tout ce que tu nous montre pas ici :
structure de la table et requete utilisée...

oui c'est sûr vue que ça le fait aussi sur phpmyadmin.. alors ya un gros select de 45 champs, 4 left join pour 20 résultats... c'est méchant 4 left join ?

[julienr]

tente un explain dans phpmyadmin ou en ligne de commande pour voir ce que fait mysql, ajoute des index en conséquence, et pour les jointures utilisent des requêtes imbriqués plutot que des jointures ca améliore pas mal les choses...

[skippyzrnr]

Je ne sais pas exactement ce que tu recupères mais si ta requete est mal faite elle peut renvoyer une tres grande quantité de lignes. J'ai deja eu ce problème il a été reglé en optimisant ma requete et en utilisant au maximum DISTINCT

[RomsIW]

Je ne sais pas exactement ce que tu recupères mais si ta requete est mal faite elle peut renvoyer une tres grande quantité de lignes. J'ai deja eu ce problème il a été reglé en optimisant ma requete et en utilisant au maximum DISTINCT

ben non, elle renvoie 20 lignes puisque je l'ai limitée.. et en l'occurrence, toutes les informations sont importantes puisqu'il s'agit de commandes, et donc toutes uniques.

[RomsIW]

tente un explain dans phpmyadmin ou en ligne de commande pour voir ce que fait mysql, ajoute des index en conséquence, et pour les jointures utilisent des requêtes imbriqués plutot que des jointures ca améliore pas mal les choses...

Voici ce que dit le "explain" :

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE D ALL NULL NULL NULL NULL 5234 Using where; Using temporary; Using filesort
1 SIMPLE PC ALL NULL NULL NULL NULL 69
1 SIMPLE C eq_ref PRIMARY PRIMARY 4 qgcom2.D.centre 1
1 SIMPLE F4 ALL NULL NULL NULL NULL 1050

[julienr]

Code: Tout sélectionner

Using filesort

si tu as un order dans ta requete c'est possible que ce soit lui qui bouffe tout
surtout si tu as beaucoup de ligne dans le tri car le limit n'agit que sur le résultat trié
-> positionne un index sur ta colonne de tri

[RomsIW]

Code: Tout sélectionner

Using filesort

si tu as un order dans ta requete c'est possible que ce soit lui qui bouffe tout
surtout si tu as beaucoup de ligne dans le tri car le limit n'agit que sur le résultat trié
-> positionne un index sur ta colonne de tri

Je crois que l'on approche du pb et donc de la solution (bien amené jusque là ) la définition de l'index a permis d'accélérer largement la requete "SELECT * FROM table ORDER BY date DESC"

Sur ma longue requête, si j'enlève le ORDER BY, ça s'accèlère très largement.

Mais AVEC l'index ET le ORDER BY, ça rame encore... ?

Merci de votre aide..

[julienr]

les index accelèrent les choses si tu as une cardinalité élevée, c'est à dire le nombre de valeurs différentes que tu as dans ta colonne...
c'est à dire combien maintenant avec l'index et combien sans le order ?

[RomsIW]

les index accelèrent les choses si tu as une cardinalité élevée, c'est à dire le nombre de valeurs différentes que tu as dans ta colonne...
c'est à dire combien maintenant avec l'index et combien sans le order ?

avec order calculé via phpmyadmin avec ma grosse requete : 7.45 sec
sans : 0.0257 sec

si c'est pas fou ça...

[ludo88]

bein si tu as que 20 résultats : pas de order, tu rentres tout dans un tableau et tu tries le tableau en post traitement.

Sinon pou info les index servent pour tous les champs dans un where, un order ou tout autre champs qui sert à limiter le nombre de lignes

[guicher]

elle fait combien de Mo ta base ?

[RomsIW]

elle fait combien de Mo ta base ?

ça je sais pas. ça me parait énorme de prendre tout dans un tableau, de faire le tri ensuite (5500 x 45 champs) en array_reverse puis de ne récupérer que les 20 premiers résultats (comment on fait d'ailleurs sur un tableau sans faire une for ?)

on peut faire autrement ? on peut pas dire que l'index de la table se fait automatiquement sur les dates décroissantes ?

merci encore

[julienr]

tu peux essayer de demander à mysql d'ordonner physiquement tes lignes sur ta colonne date, mais je ne sais pas ce que cela vaut