Discussion :

[encoremoi21258]

Bonsoir,

Mon explication ne correspond pas vraiment à la réalité, je vais simplifier l'explication de ce à quoi sert ce que je fais.

Je possède une base de données avec une table unique qui contient les comptes utilisateurs de mon site.
Je possède une autre base de données avec un table qui contient plus de 2 500 000 enregistrements.

En faite chaque utilisateur peut obtenir 1000 choses différentes, et donc dans une table j'ai mis une colonne avec le nom d'utilisateur, une autre avec le numéro de la chose obtenue, une dernière colonne avec un enum avec OUI ou NON en fonction de si la chose a été obtenue.

Cela permet donc via un SELECT avec pour seul paramètre le nom d'utilisateur, tout ce que cet utilisateur a obtenu, ou pas obtenu.

Le problème est que la requête UPDATE pour mettre à jour la dernière colonne, celle qui indique si la chose a été obtenue ou non, a un temps d'exécution de 6 à 7 secondes. C'est beaucoup trop pour mettre à jour des centaines d'enregistrements via une tâche cron.

Quand je fais un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

EXPLAIN UPDATE SuccesItemObtenu SET DejaObtenu = 'OUI' WHERE PlayerID = "Shart" AND IdObjet= 327;

je constate que ça parcours plus de 1 500 000 lignes avant d'arriver à trouver l'enregistrement correspondant, et j'imagine que c'est ce qui explique la lenteur.

Et pourtant je suis sur un serveur dédié.

Du coup j'aimerais savoir s'il y a une solution pour accélérer l'UPDATE de façon à ce que la tâche cron ne se prenne pas systématiquement un timeout alors que moins de 2% des requêtes ont été effectuées.

Merci d'avance

[sevyc64]

Je ne connais rien en MySql, mais bon, ça fonctionne pareil sur tous les sgbds.

J'imagine que IdObjet est une clé primaire, il doit donc y avoir, surement automatiquement, un index dessus.

Par contre quand est-il de PlayerId, as-tu un index de créé sur cette colonne ?

[encoremoi21258]

Bonsoir,

Il n'y a aucune clé primaire. D'ailleurs une clé primaire est unique, non ? IdObjet est présent autant de fois qu'il y a de PlayerID différents, et PlayerID est présent autant de fois qu'il y a d'IdObjet différents. Par contre le même couple PlayerID et IdObjet n'est présent qu'une seule fois.

Par hasard j'ai regroupé des conditions WHERE dans la même requête UPDATE avec un truc du genre (PlayerID = "iopp" AND IdObjet = 456) OR (PlayerID = "nbc" AND IdObjet = 145) et avec seulement 200 'OR' la quête a nécessité 3 minutes et 48 secondes pour s'exécuter ... du coup c'est impensable d'en faire le double voir plus encore si le nombre d'utilisateurs augmente.

Edit:
Alors là je viens de faire quelque chose que je ne comprend pas ...
Via SQLYog je suis allé dans la partie qui permet d'éditer une table, et j'ai mis un index sur les colonnes PlayerID et IdObjet en indiquant "UNIQUE" dans le type d'index. Et là les 490 UPDATE prennent 0.268 secondes. Je ne comprend plus rien ... Est-ce bien cela qu'il fallait faire ? Et pourquoi d'un coup est-ce aussi rapide ?

[sevyc64]

Oui c'est cela qu'il fallait faire, le miracle de l'index

[encoremoi21258]

Je croyais que vous me demandez de mettre une clé primaire et du coup j'avais du mal à imaginer la chose car aucune valeur n'est unique mais seulement la combinaison de 2 colonnes.

Enfin bon tant que j'ai la solution à ce problème c'est parfait, je l'utiliserais à chaque table volumineuse

Merci beaucoup.

[sevyc64]

Au besoin, la clé primaire pourrait très bien être la combinaison des 2 colonnes. On appelle ça une clé composée

Enfin, j'imagine que aussi possible sur MySql

[badaze]

Bonsoir,
...
Alors là je viens de faire quelque chose que je ne comprend pas ...
Via SQLYog je suis allé dans la partie qui permet d'éditer une table, et j'ai mis un index sur les colonnes PlayerID et IdObjet en indiquant "UNIQUE" dans le type d'index. Et là les 490 UPDATE prennent 0.268 secondes. Je ne comprend plus rien ... Est-ce bien cela qu'il fallait faire ? Et pourquoi d'un coup est-ce aussi rapide ?

C'est le rôle des index. Imaginons que tu fasses une requête pour chercher toutes les enregistrements de l'utilisateur n° 1000.

Si tu n'as pas d'index (et à fortiori pas de clé) le SGBD doit parcourir les 2.500.000 enregistrements pour être sûr d'avoir tout lu. Si tu as un index sur le n° d'utilisateur, le SGBD va seulement lire les enregistrements qui correspondent à 1000. Donc si tu as 100 enregistrements pour cet utilisateur tu économises 2.499.900 lecture. C'est donc beaucoup plus rapide.

[Dendrite]

Sinon, si ça n'est pas une base trop sensible tu pourrais nous mettre le sql de la structure de toutes tes tables (sans les données biens sûr !) ?
Tu as peut etre encore beaucoup d'améliorations à faire...