si potrebbe benissimo fare un sistema che, passandogli l'identificativo dell'utente, sbroglia tutta la situazione

il tutto però attivando nel contempo anche un lock (memcache, apc o file) per evitare che magari il cron scatti nel contempo o per evitare che magari il cron in esecuzione "raddoppi" il risultato delle operazioni

il lock sull'intera tabella sarebbe da evitare perché altrimenti si bloccano tutti

un alternativa, per lavorare in modo distribuito, potrebbe essere evitare l'uso di mysql e sfruttare un meccanismo di caricamento da file, lo so, può sembrare anomalo, ma i sistemi (realmente) distribuiti non operano direttamente sul singolo file

un modo, ad esempio, per ridurre il problema delle performance e, nel contempo evitare problemi di locking, è (quasi) semplice, ovvero si potrebbe utilizzare un filesystem come GFS2.

In questo modo i file dei dati sono dei semplici file serializzati:
- espandere il sistema comporta la semplice aggiunta di una macchina al cluster dati o al cluster elaborazione e via, utilizzare mysql-cluster, per ottenere lo stesso livello di flessibilità, richiede più esperienza e soprattutto un budget iniziale più corposo
- per ridurre il carico del sistema, benché il file venga comunque messo in cache dal sistema operativo, si può disabilitare questa funzionalità ed utilizzare apc o memcache in loco così da avere uno "storico" dei dati caricati sempre in memoria
- alla nota precedente andrebbe accoppiato un load balancer (nginx) configurato per assegnare al nodo meno carico il client per poi continuare a farlo assegnare allo stesso client (un semplice check sui cookie basterebbe)

mysql, in un contesto del genere, è relativamente utile ... infatti i dati girano generalmente attorno ad un singolo elemento, quindi creando dei bei file serializzati in cartelle/sottocartelle (così da evitare che troppi file in una sola cartella facciano impazzire il sistema) e magari spezzi i dati in più file (uno contenente le informazioni sul player, uno per villaggio contenente le risorse, le truppe e le strutture, uno per i messaggi e via dicendo ... così eviti di caricare in memoria troppa immondizia che non serve, leggasi i messaggi del player possono anche essere letti direttamente dal disco, tanto se attende un 30° di secondo in più non succede nulla ... in compenso tutto il resto va più veloce di assai):
- ricevi la richiesta
- verifichi se è presente il lock
- attivi il lock sul player
- verifichi se il player risiede in memoria
- se no, carichi il file/i file del player e lo inserisci in memoria
- esegui le operazioni di calcolo costruendo una timeline e analizzando poi a blocchi le varie parti della timeline delle operazioni
- ...

la comodità, però, di non avere dietro mysql è quella di

per gestire la timeline degli eventi potresti semplicemente scriverli così come sono in un elenco ordinandolo per data, in questo modo quando la procedura fa le operazioni sa benissimo che arrivati a quel dato momento deve ricomputare le risorse prodotte per ora e via dicendo

comunque, lo so, ho divagato eccessivamente probabilmente