Le problème ne serait pas déjà la requête SELECT : on récupère tous les évènements non traités. Mais pour deux exécutions de scripts concurrentes elles vont avoir +/- les mêmes données et donc tous les traiter, qu'il y ait eu mise à jour depuis leur propre lecture ou non.
Sinon commencer la transaction dès le début, le SELECT des évènements en mode FOR UPDATE (verrouillages des lignes lues) par contre les autres processus seront probablement mis en attente avant de pouvoir lire la table. S'il le faut, il doit être possible de réduire le temps d'attente via le paramètre innodb lock wait timeout avant que ça ne plante.
Enfin, tout dépend comment s'emboîte et doit s'emboîter le tout. L'exécution de cette tâche par les joueurs est plutôt délicate.
Sinon commencer la transaction dès le début, le SELECT des évènements en mode FOR UPDATE (verrouillages des lignes lues) par contre les autres processus seront probablement mis en attente avant de pouvoir lire la table. S'il le faut, il doit être possible de réduire le temps d'attente via le paramètre innodb lock wait timeout avant que ça ne plante.
Enfin, tout dépend comment s'emboîte et doit s'emboîter le tout. L'exécution de cette tâche par les joueurs est plutôt délicate.