Discussion :

[Eric80]

J'aide un collègue pour améliorer les performances d'un serveur LAMP.
Un des gros pb est la lenteur du à de multi select sur une table de 100 MB.
Le site est multi utilisateur, et chacun a des informations ds cette table.
La solution qui me semble la + efficace est de créer une table temporaire correspondant à l'ID du user lors du login et que tous les SELECT se fassent sur cette table temporaire au lieu de la table principale.
Afin d'éviter un complexe algo de syncrhro, l idee est de faire les SELECT que sur la table temporaire, et tous les INSERT/ALTER/UPDATE en // sur la table temp et la table principale.
J'ai fait qques essais sur les SELECT only: c'est en effet 100 fois + rapide!
Le site est en PHP. Et le login utilise les sessions PHP.
La question est de savoir comment au mieux supprimer (DROP) ma table temporaire?
Lors d'un fonctionnement normal, clairement au niveau du log out. Mais quid si la session est perdue?
Cela me semble peu adapté à une variable de sessions, surtout ci celles ci sont écrites sur le HDD: l interet de la table temp est aussi que tout se fasse en RAM plutot que des SELECT sur une table sur le HDD.
Je ne connais pas bien le systeme des sessions PHP. Comment une session peut etre perdue?
Si il s'agit d'un timeout, j'ai pensé faire mon DROP juste avant celui ci (cad par exemple à la 29ème min si le timeout est de 30min).
A quels cas dois je aussi penser?
Que pensez vous de ma solution?

J'ai pensé aussi à améliorer le modele de la DB, mais seulement en 2nd recourt. J'aimerais autant que possible éviter d'y toucher (dangeureux pour l integrité des donées, dépendances, relations, etc)
D'ailleurs, j'ai fait qques essais rapide de l'une et l'autre solution. Le gain de performance le plus significatif est avec les table temp.
Evidement, le top serait de combiner les 2.

La question que je me pose surtout est de savoir si mon concept tient vraiment la route.

[gorgonite]

euh sinon vous avez déjà mis des index & cie... ?

[Eric80]

C'est vrai que j'aurais du commencer par là.
Je viens de mettre un index sur le champ userID de la table principale, et cela change tout!
Que fait cet index au juste?

Peut on imaginer que mysql fasse avec de lui meme des optimisations similaires à ce que je décris ici (table temp sur l index) ?

[gorgonite]

pour simplifier avec un index, il a créé une table intermédiaire bien plus petite qui permettra d'accélérer les requêtes ultérieures... enfin si l'index est bien pensé.

Peut on imaginer que mysql fasse avec de lui meme des optimisations similaires à ce que je décris ici (table temp sur l index) ?

a ma connaissance, mysql ne sait rien faire... mais est très à la mode.

perso, je pense que beaucoup de gens devraient mieux penser à la phase de conception des tables... cela peut changer énormement de choses sur les performances finales en prod