Bonjour,

J'ai une requête composée de 3 order by qui me sort un classement.

Je souhaite pouvoir localiser le plus rapidement possible quelqu'un dans le classement (ex : il est 427ème sur 10 000).

Je n'ai pour l'instant trouvé la possiblité que de lister le résultat de la requête jusqu'à ce qu'on tombe sur la personne recherchée, ça fonctionne biensûr mais ce traitement est amené à être effectué à une cadence assez élevé et je me retrouve confronté à un problème de performance.

A part le fait de trier les données associées à un id directement à la source dans la bdd (un système de cache en gros), voyez-vous une autre solution ?

Merci

Pas besoin de trier pour accélérer l'accès à une ligne dans une table. Un bon index suffit.

Les index servent à la requête de génération du classement mais pas pour mon problème en fait.

Dans la bdd c'est dans l'ordre 0,1,2,3 etc mais je travaille sur un classement issu d'une requête composée de 3 order by, les index ne servent pas à ce niveau (sauf si j'utilise une table de cache mais je cherche une autre solution justement).

Est-ce qu'il est posible d'avoir la structure de la (ou des?) table(s) ainsi que la requête ? Ça nous faciliterait la tâche pour trouver une amélioration

Il faut que tu places tes index sur les colonnes qui sont triées par les 3 order by.
Ainsi, quand tu va lancer le tri sur ta table, les index vont augmenter la vitesses de tri et améliorer tes performances

Les index servent à la requête de génération du classement mais pas pour mon problème en fait.

Dans la bdd c'est dans l'ordre 0,1,2,3 etc mais je travaille sur un classement issu d'une requête composée de 3 order by, les index ne servent pas à ce niveau (sauf si j'utilise une table de cache mais je cherche une autre solution justement).

Deux choses:

1. Si le but est de trouver une ligne d'un tableau de résultats, je peux comprendre ton souci d'éviter un deuxième accès à ta table MySQL mais, pour trouver une valeur dans un tableau à deux dimensions (typique d'un tableau de résultats d'une requête), il n'y a pas de miracle, la fonction array_search ne marchera pas. Il te faudra complètement traverser ton tableau de résultats. Pas optimum.
   
   Il sera infiniment plus efficace de faire les frais d'un deuxième accès à ta table MySQL.
   
   A titre d'exemple, je viens de faire quelques essais.

   Code : Tout sélectionner

   # recordset de 10.000 lignes Recherche PHP dans le tableau de résultats 0.2106 sec Requête MySQL sur la table SANS index 0.0151 sec. Requête MySQL sur la table AVEC index 0.0004 sec. # recordset de 100.000 lignes Recherche PHP dans le tableau de résultats 2.0821 sec Requête MySQL sur la table SANS index 0.2458 sec. Requête MySQL sur la table AVEC index 0.0004 sec.
   Tu vois que même lorsque tu demandes à MySQL de lire séquentiellement une table non indexée, il le fait de manière plus efficace. Et avec l'utilisation d'index, il n'y a pas photo.
2. S'il s'agit simplement d'accéder au x ième enregistrement de ton tableau de résultats, c'est très simple, utilise l'indice numérique du tableau (plus 1 car ce tableau commence à 0)

Pour te conseiller plus avant, il nous faut un exemple maintenant.

1. Si le but est de trouver une ligne d'un tableau de résultats, je peux comprendre ton souci d'éviter un deuxième accès à ta table MySQL mais, pour trouver une valeur dans un tableau à deux dimensions (typique d'un tableau de résultats d'une requête), il n'y a pas de miracle, la fonction array_search ne marchera pas. Il te faudra complètement traverser ton tableau de résultats. Pas optimum.
   
   Il sera infiniment plus efficace de faire les frais d'un deuxième accès à ta table MySQL.
   
   A titre d'exemple, je viens de faire quelques essais.

   Code : Tout sélectionner

   # recordset de 10.000 lignes Recherche PHP dans le tableau de résultats 0.2106 sec Requête MySQL sur la table SANS index 0.0151 sec. Requête MySQL sur la table AVEC index 0.0004 sec. # recordset de 100.000 lignes Recherche PHP dans le tableau de résultats 2.0821 sec Requête MySQL sur la table SANS index 0.2458 sec. Requête MySQL sur la table AVEC index 0.0004 sec.
   Tu vois que même lorsque tu demandes à MySQL de lire séquentiellement une table non indexée, il le fait de manière plus efficace. Et avec l'utilisation d'index, il n'y a pas photo.

Oui voilà c'est exactement ça, donc pas d'autres solutions envisageables que de mettre le résultat en cache dans une bdd et de refaire un accès à la bdd

Oui voilà c'est exactement ça, donc pas d'autres solutions envisageables que de mettre le résultat en cache dans une bdd et de refaire un accès à la bdd

Il faudrait détailler un peu et donner un exemple car là, on risque de tourner en rond.

Structure de tes tables, ta première extraction et les requêtes suivantes. Il y a peut-être moyen de faire autrement que de créer une table temporaire.