I had the same problems when starting to work on my hobby game (aimed more at learning & experimenting with things).
It does not matter where I ended up (that is stackless python and websockets) - only know that I did run tests using PHP CLI, where a PHP process would be used a a *persistent* game logic buffer somewhere along the way between the database (where truly persistent game data is being held) and the clients.
Main reason: the lock mechanisms mentioned in ToohrVyk's excellent post above. I found it easier and more flexible to move the queueing complexity to a "persistent server" rather than deal with it at database level. This intermediate server can then be used as several things: real game state cache (persistent in memory), able to write-through or write-back to the DB at predetermined times/intervals or on demand. Not perfect, obviously, but once the game world is "loaded", the database basically goes to sleep.
Then arises the issue of talking with that PHP-CLI process using HTTP. Because afik, Apache is then not available... sockets are, however.
Also consider this idea: are universal ticks necessary in your game? Is progression fine-grained enough to allow desynchronised updates between players? (as in: would the fact that player A gets his resource X updates a few seconds before player B gets his resource Y be game-breaking?). I found out that in my hobby dev process, it was the case: updates could run be asynchronously. That is true within a same faction and between factions. So "faction" updates all run independently of one another - which dilutes the load over time. Any "locking" mechanism can then be made compulsory at game logic level - and only when unit/monster/resource/whatever interaction makes it so (combat, resources sharing, and the like).
My 2 [s]€ [/s]£ cents
Plopo
PS: could not help remembering this jewel: nothing to do with anyone on this thread, so here goes for the laughs
http://thedailywtf.com/Articles/Multithreaded-PHP-.aspx
