TourDeJeu, le réseau des jeux en ligne alternatifs : jeux web multijoueurs, jeux par forum. En savoir +

Flux RSS des discussions du forum : pour les joueurs, et pour les créateurs et MJ
  Reply to this topicStart new topicStart Poll

> Éviter De Parcourir Toute Une Table., Mais calculer un nombre d'occurence.
Sybler
Ecrit le : Vendredi 23 Octobre 2009 à 18h56
Quote Post


Ouf
*

Groupe : Membre
Messages : 453


Bon, alors j'ai remarqué dans mes statistiques MySQL que j'avais 2 valeurs assez critiques:
QUOTE

Handler_read_rnd  245 k  Le nombre de requêtes de lecture d'un enregistrement basée sur une position fixe. Ce nombre est élevé si vous faites de nombreuses requêtes qui nécessitent de trier les résultats. Vous avez probablement un grand nombre de requêtes qui demandent à MySQL de parcourir des tables en entier, ou vous avez des jointures qui n'utilisent pas correctement les clés.

Handler_read_rnd_next  81 M  Le nombre de requêtes de lecture du prochaine enregistrement dans le fichier. Élevé si vous faites plusieurs parcours de tables. Ceci suggère que vos tables ne sont pas correctement indexées ou que vos requêtes ne sont pas écrites de façon à tirer parti des index que vous avez définis.

À noter que ces chiffres sont sur 4 jours uniquement.

Donc du coup, je repense à comment mes codes et DB fonctionnent, et sur ma page principale, j'indique le nombre de messages que comporte l'historique des messages du joueur. Un peu comme votre boite de mail qui dit que vous avez 5124 messages au total.

Or, pour obtenir ce chiffre, logiquement, MySQL doit parcourir l'ensemble de la table. Comme la mienne comporte un peu plus de 300 000 enregistrements, c'est fastidieux.

Ceci étant dis, je crois que ma table est bien indexée.


Avez-vous une solution pour ce type de problématique ?


--------------------
user posted image
PMEmail PosterUsers Website
Top
pascaltje
Ecrit le : Dimanche 25 Octobre 2009 à 11h11
Quote Post


Ouf
*

Groupe : Membre
Messages : 242


Tu peux optimiser en stockant le total pour le joueur :

Avantages :
- lecture plus rapide

Inconvénients :
- dénormalisation de la DB
- risque d'incohérence de données
- il faut recalculer le total à chaque ajout / suppression des données comptées.

Je crois que ça vaut le coup de tenter.

A+

Pascal


--------------------
PMEmail PosterUsers Website
Top
Findel
Ecrit le : Dimanche 25 Octobre 2009 à 13h11
Quote Post


Pro
*

Groupe : Membre
Messages : 99


La piste de pascaltje est pas mal, pour l'avoir mis en place, je peux effectivement dire que cela permet de gagner pas mal.

Ceci dit, pour te conseiller plus finement il nous faudrait la structure de ta table (savoir sur quelles colonnes sont tes index, et dans quel ordre) et cette fameuse requete qui compte le nombre de message.

En effet, si par exemple tu t'amuse à parcourir toute la table et à compter le nombre d'enregistrement côté PHP au lieu de faire un COUNT dans la requete SQL, ça va faire sacrément varier les performances.
PMEmail PosterUsers Website
Top
Sybler
Ecrit le : Mardi 14 Septembre 2010 à 15h28
Quote Post


Ouf
*

Groupe : Membre
Messages : 453


Je repasse tongue.gif

Ouais, finalement j'ai créé un champ qui garde le compte. Le seul problème que j'ai eu, c'est que j'ai parfois des deadlock, du coup il y a parfois une certaine désynchronisation qui se produit.

Sinon Findel, lorsque tu fait un COUNT, mysql fait un FULL TABLE SCAN. Oui il est plus performant de faire un COUNT que de calculer dans une boucle ou un truc du genre (ca c'est l'horreur), mais ca demeure très peu performant sur de grande tables.


--------------------
user posted image
PMEmail PosterUsers Website
Top
« Sujets + anciens | Programmer | Sujets + récents »

Reply to this topicStart new topicStart Poll