Discussion :

[TedLun]

Bonjour à tous,

Je rencontre une difficulté sur laquelle je coince un peu, et qui pourtant doit être assez courante. Bizarrement j'ai cherché un peu partout sur le net et je n'ai pas réussi à trouver de doc sur ce sujet...
J'ai une table avec assez peu de lignes, environ 90 000, mais avec pas mal de champs et d'index (il s'agit d'un catalogue produits).

En ce qui concerne les requêtes SELECT aucun soucis la table est optimisée et très réactive, mais au niveau des UPDATE là par contre le traitement est très long : jusqu'à 8 secondes pour mettre à jour 1 champ sur 1 ligne.
J'ai tenté les commande de réparation, vérification, optimisation, etc. Mais ça ne change rien.

Je me suis rendu compte que le problème était lié au trafic sur le site : si je copie la table sous un nouveau nom (donc non consultée), les requêtes d'UPDATE sont à nouveau instantanées. En général il y a environ 30 à 40 requêtes simultanées sur cette table.

Je me demandais donc si l'un d'entre vous avait déjà rencontré ce problème et comment il l'avait contourné?

Merci!

[escartefigue]

Bonjour,

C'est probablement du justement à votre table dite "obèse" c'est à dire avec un très grand nombre de colonnes.

Une table "obèse" est symptomatique d'une erreur de modélisation par non respect des formes normales.
Cas typique, et malheureusement très fréquent : la table des personnes qui contient non seulement le nom, le prénom, la date de naissance etc.., mais aussi les n° de téléphone, les adresses etc...

Les conséquences sont que les applis qui mettent à jour la partie signalétique (nom, prénom, date de naissance) celles qui mettent à jour les adresses et celles qui mettent à jour les contacts (tél, mail)... sont en concurrence lorsqu'il s'agit du même individu ou d'individus dont les données sont sur la même page.
Alors qu'avec, toujours dans le même exemple, une modélisation rigoureuse (une table signalétique, une table adresses et une table contacts), il n'y aurait aucune concurrence d'accès.

Communiquez le DDL de votre table et de ses index pour en avoir le coeur net

Communiquez aussi votre requête UPDATE, elle peut également être à l'origine du problème

[TedLun]

Effectivement ce point m'avait complètement échappé, j'étais plutôt parti sur un problème lié à la config de mysql...

Ce qui me paraissait assez surprenant c'est le fait que sur cette table il ne peut y avoir qu'une seule requête UPDATE à la fois, et que les nombreuses requêtes SELECT simultanées restent pour autant extrêmement rapides.
Le point que j'avais zappé c'est le nombre important d'index que comporte cette table. J'ai une autre table du même genre à coté qui possède pas mal de colonnes, avec presque le même nombre de lignes et le même trafic, mais seulement 3 index, et là aucun souci avec les UPDATE.

En fait le problème concrètement c'est que la reconstruction des index doit être vraiment très longue à chaque modification d'une des valeurs. Maintenant il me reste à bosser sur la structure de la table pour permettre une recherche rapide tout en réduisant le nombre d'index. Et pour ça effectivement pas le choix il va falloir diviser la table...

Du coup maintenant au boulot
Merci d'avoir pris le temps de me répondre