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?

En ce qui concerne l'utilisation des sessions , tu trouvera une doc complète et des exemples sur le site http://php.net/session
Tu notera qu'il est possible de donner à PHP des fonction de registration/déregistration de sessions pour gérer toi même des paramètres plus complexes, comme une base de donnée.
 
En ce qui concerne la solution adoptée, elle me paraît plutôt originale... A tu quand même vérifié qu'en organisant différemment ta base, et en utilisant des index adéquats, tu n'améliorerai pas les perfs?

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 qque essais de l'une et l'autre solution. Le gain de performance le plus significatif est sur ma solution.
Evidement, le top serait de combiner les 2.
 
La question que je me pose est surtout de savoir si mon concept tient vraiment la route.

la solution la plus fiable pour gêrer un timeout de session, comme indiqué par quelqu'un dans un autre post, serait de stocker dans ta table temporaire la date de dernière activité de l'utilisateur.
A chaque page vue par un utilisateur, tu fais deux choses :  
- tu update sa table avec le timestamp courant
- tu vires toutes les tables temp dont la date de dernière activité est inférieure à (timestamp courant) - (le timeout de session)
 
Alors oui, il restera des tables non supprimées quand y aura plus un seul utilisateur sur le site, mais c'est pas trop un problème, le premier a se relog fera le ménage.
Après, ce principe de faire "bosser" un utilisateur pour les autres est discutable. Moi je pense que c'est pas bien méchant.

Idée intéressante. Du coup, je n'ai peut etre meme pas besoin d'une table temporaire par utilisateur.
Une seule table temporaire pourrait faire l'affaire, si elle est régulièrement actualisée comme tu le proposes. De toute facon, les données sont extraite d'une base commune.
Si il y a 300 users, je ne pense qu'il y a jamais plus de 10 users en simultané, soit une table temporaire de qques MB si possible en RAM au lieu des 100 MB à relire depuis le HDD.
D'autre avis?
 
La question reste de savoir comment je peux conserver cette variable en RAM pour éviter les accès HDD répétés lors des requètes suivantes sur la table. La table devra en effet etre lisible par plusieurs fichiers différents.  
Possible d'en faire une variable globale > variable de session ?

Personnellement, j'étudierais une solution de ce type :  
- une table qui stocke les "sessions" ouvertes. c'est à dire qu'à chaque connexion à la base (à chaque page consultée, en fait), le script met à jour la dernière heure d'utilisation
- régulièrement (15 minutes ?), un script passe, regarde toutes les sessions périmées (date de dernier accès plus vieux que la durée d'une session PHP) et les supprime (l'entrée dans cette table et toutes les tables "temporaires" correspondantes

Comme bcp me parlent d'index, je viens en effet de mettre le userID sur ma base principale en index, et cela change tout!
J'aurais du commencer par là avant de se lancer dans toutes ces considérations!

Y a t il des risques pour mes données avec cet Index? Que cela fait il au juste?

 
Euh ... oui, il vaudrait mieux commencer par là  
 
Un index, c'est une sorte de raccourci. Le SGBD stocke à part les données de l'index. Lors d'une recherche (sur l'un des champs de cet index), il parcourt l'index, ce qui est plus rapide car moins volumineux que la table complète. Ca lui permet de déterminer quelles sont les lignes à récupérer, qu'il va chercher directement dans la table, sans lire celle-ci entièrement

Bon, je viens de l'ajouter sur mon server de production.
La différence est nette.
Dans mes tests en local, un button de mon appli générait la lecture de 3 Go de données ("octets de lecture E/S" pour mysqld ds le taskmanager de windows). Avec l'index, je suis tombé à 55 MB et par la meme une réponse bcp plus réactive.
 
En fait cet index fait notamment tout seul ce que je voulais faire avec ma table temporaire...

les indexs, c'est pas fait pour les chiens!
Sérieux, renseigne toi aussi sur le type d'index nécessaire, et fait des test.
Il y a grosso modo deux types:
- B-arbres: + rapide pour les comparaisons <= et >=
- Hash: + rapides pour les comparaisons = et !=
De plus MySql permet de spécifier une méthode de stockage dont:
MyISAM (par défaut il me semble), MEMORY
Vérifie ce qu'il semble le plus approprié sur le site http://mysql.org/

en fait,  c est dommage que mysql ne gère pas les FOREIGN KEYS.
Il faut donc mettre à la main toutes les FOREIGN KEYS en INDEX.

Si, MySQL gère la notion de clés externes  
(je crois avoir utilisé ca dans une vie antérieure )

oui, mais en InnoDB seulement, pas en MyISAM  
 

Source: http://dev.mysql.com/doc/refman/5. [...] -keys.html