MySQL : Pb de requete UPDATE très lente
5 messages • Page 1 sur 1
Consultez la formation à Google Analytics de WebRankInfo / Ranking Metrics
MySQL : Pb de requete UPDATE très lente
Bonjour !
Je vous expose mon problème :
Je dispose d'une table qui comporte environ 8.000.000 d'entrées.
Elle est de format fixe, et comporte tous les index nécessaires pour effectuer rapidement les requetes.
D'ailleurs, les requetes SELECT s'effectuent toutes très rapidement.
En revanche, les requetes du type : " UPDATE table SET lu='oui' WHERE id=123456 " sont par période très très lentes (plusieurs dizaines de secondes).
Or le champ "id" est pourtant la clé primaire, et la table n'est jamais vérouillée au moment où la requete démarre.
J'ai pensé à un problème de mise à jour des index. En effet, ma table fait le poids suivant :
Données : 732 044 Ko
Index : 634 420 Ko
Total : 1 334 Mo
Mais lorsque j'effectue des INSERT, je n'observe pas ce pb.
Auriez-vous une idée de l'origine de telles lenteurs ? Peut-être la config du serveur Mysql, ou bien un problème dans les Index (mais un OPTIMIZE a été effectué très récemment ....)
Merci pour votre aide
Je vous expose mon problème :
Je dispose d'une table qui comporte environ 8.000.000 d'entrées.
Elle est de format fixe, et comporte tous les index nécessaires pour effectuer rapidement les requetes.
D'ailleurs, les requetes SELECT s'effectuent toutes très rapidement.
En revanche, les requetes du type : " UPDATE table SET lu='oui' WHERE id=123456 " sont par période très très lentes (plusieurs dizaines de secondes).
Or le champ "id" est pourtant la clé primaire, et la table n'est jamais vérouillée au moment où la requete démarre.
J'ai pensé à un problème de mise à jour des index. En effet, ma table fait le poids suivant :
Données : 732 044 Ko
Index : 634 420 Ko
Total : 1 334 Mo
Mais lorsque j'effectue des INSERT, je n'observe pas ce pb.
Auriez-vous une idée de l'origine de telles lenteurs ? Peut-être la config du serveur Mysql, ou bien un problème dans les Index (mais un OPTIMIZE a été effectué très récemment ....)
Merci pour votre aide
à mon avis vu la taille de ta base, c'est la mise à jour des index qui est longue. Quand tu fais un insert c'est rajouté à la fin de ta base donc ça doit être facile à mettre à jour pour l'index par contre quand tu fais un update tu dois le forcer à recréer une partie de l'index à chaque champ enregistré. J'ai un copain qui bosse sur des tables très volumineuses aussi et qui quand il diot faire des updates important, il supprime l'index avant l'opération et le recrée juste après, c'est plus rapide.
Oui ça vient de ça.
Mais tu as énormément d´entrée dans ta table, aussi tu ne peux pas spécialiser plus tes tables, et répartir ainsi les requêtes sur différente tables?
Sinon, pour les requetes très longue, il faudrait (dans le cas ou tu ne règle pas ce problème d´index) lancer ton script en parallèle, par une autre connexion. Comme ça ce temps d´accès ne se répaercutera pas normalement.
Mais tu as énormément d´entrée dans ta table, aussi tu ne peux pas spécialiser plus tes tables, et répartir ainsi les requêtes sur différente tables?
Sinon, pour les requetes très longue, il faudrait (dans le cas ou tu ne règle pas ce problème d´index) lancer ton script en parallèle, par une autre connexion. Comme ça ce temps d´accès ne se répaercutera pas normalement.
En fait, il s'agit d'une table referançant les informations liées à des messages que s'échangent des membres (en gros : l'expediteur, le destinataire, l'IP, ..)
Moi aussi, je pense à un pb d'index, mais ce qui est étrange, c'est que c'est très irrégulier : la requete peut être instantannée comme elle peut prendre 30 sec.
Si je trouve une solution je vous le fais savoir
Moi aussi, je pense à un pb d'index, mais ce qui est étrange, c'est que c'est très irrégulier : la requete peut être instantannée comme elle peut prendre 30 sec.
Si je trouve une solution je vous le fais savoir
en fait, c´est aléatoire car l´emplacement dans l´index est aléatoire...
Et donc tout dépend de la taille de cette partie d´index que la base doit regénérer...
Mais dans ce cas, tu ne peux pas essayer de faire au lieu de l´update une fonction comme ça:
Select -> récupère les anciennes valeurs
Delet -> l´ancienne entrée
Insert -> la nouvelle entrée
Aucune idée si cela va mieux marcher, et si ça te convient mais bon...
Et donc tout dépend de la taille de cette partie d´index que la base doit regénérer...
Mais dans ce cas, tu ne peux pas essayer de faire au lieu de l´update une fonction comme ça:
Select -> récupère les anciennes valeurs
Delet -> l´ancienne entrée
Insert -> la nouvelle entrée
Aucune idée si cela va mieux marcher, et si ça te convient mais bon...
5 messages • Page 1 sur 1
Formation recommandée sur ce thème :
Formation Google Analytics : en 2 jours, apprenez comment exploiter l'essentiel des possibilités de l'outil de mesure d'audience de Google. Formation animée par Julien Coquet, expert certifié officiellement par Google Analytics.
Tous les détails sur le site Ranking Metrics : programme, prix, dates et lieux, inscription en ligne.
Lectures recommandées sur ce thème :
- Passage à l'heure d'été/hiver sur un forum phpBB
- Google Update Jagger : étape 2 sur 3
- Historique des "Google Update"
- Des changements dans l'algorithme de Google ? (22 février 2007)
- Google API : guide de développement de l'API Google
- Gestion des langues et des sessions en PHP / MySQL
- La mise à jour du mois de juillet arrive...
- Nombre moyen de mots par requête : statistiques AOL Août 2006
- La Google Dance Gilligan n'en était pas une
- API Blogger : Google Data API
Qui est en ligne
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 0 invités





le forum