31-05-2018, 10:00 PM
Salut,
Dans les cas où c'est nécessaire, je ne lock pas la table (c'est une catastrophe en terme de concurrences). Au lieu de cela, j'encapsule dans une transaction et basta (souvent largement suffisant, étant donné que MySQL est censé fournir une lecture consistante des données).
Quand des SELECT sont à faire, j'utilise également FOR UPDATE or LOCK IN SHARE MODE suivant le cas d'utilisation (cf doc https://toile.reinom.com/les-astuces-et-...ql-queries )
Bon, après, pour nos usuels petits jeux web à 100 voire 1000 joueurs actifs (et encore), les temps de traitement et de lock SQL sont censés être très courts. Si ce n'est pas le cas, c'est que tu as probablement mal construit ta requête SQL.
Citation : Pour vos jeux, quand vous devez boucler puis mettre à jours les données de vos joueurs, comment procédez quoi ?Perso, c'est rare. Souvent, une seule requête suffit. Eventuellement, une table d'integers peut aider pour cela (perso, j'ai toujours une table "integers" composée d'une seule colonne "n INT UNSIGNED" remplie avec tous les entiers de 0 à ~1.000.000; ça ne coûte rien en stockage, mais cela permet d'émuler quelques trucs que MySQL ne sait pas faire nativement [nota: MySQL 8, sorti depuis peu, propose quelque chose de similaire via les window functions et ROW_NUMBER de mémoire])
Dans les cas où c'est nécessaire, je ne lock pas la table (c'est une catastrophe en terme de concurrences). Au lieu de cela, j'encapsule dans une transaction et basta (souvent largement suffisant, étant donné que MySQL est censé fournir une lecture consistante des données).
Quand des SELECT sont à faire, j'utilise également FOR UPDATE or LOCK IN SHARE MODE suivant le cas d'utilisation (cf doc https://toile.reinom.com/les-astuces-et-...ql-queries )
Citation :waiting for table level lockCe n'est pas normal: tu devrais plutôt avoir un ROW lock et non un TABLE lock. Nota que MyISAM ne permet pas le lock des rows: passe en InnoDB si tu étais dessus.
Citation :du coup le temps d'exécution s'allonge. Le fait de bloquer, pénalise les accès [...] l'accès à la table est plus longueTout à fait. Tant qu'une ROW est "lock", les autres clients SQL ne peuvent y accéder. Si une requête a besoin de verrouiller une ligne (ie: lors d'un UPDATE dans une transaction) alors cette requête attend que la ligne ne soit plus verrouillée en écriture, puis elle pose son verrou, l'édite, et jusqu'à ce que le verrou soit relâché, les autres requêtes poireautent (sauf éventuellement si elles ont demandé des options type "zappe les verrous et ignore ces lignes"). Note qu'une lecture (SELECT) ne pose pas de verrou en écriture (une requête peut faire son SELECT sans bloquer une autre requête), sauf si la première requête SELECT a préciser de verrouiller la ligne (FOR UPDATE)
Bon, après, pour nos usuels petits jeux web à 100 voire 1000 joueurs actifs (et encore), les temps de traitement et de lock SQL sont censés être très courts. Si ce n'est pas le cas, c'est que tu as probablement mal construit ta requête SQL.