Regarding #2: querying and updating a database for every change of game state is an extremely good idea, as long as you're using a right database.
Obviously things like MySQL can be subpotimal in such cases (or maybe not; it depends on the size of the game state and the complexity of your model). If you use a low-overhead NoSQL database that only stores things to disk when it has time, you'll have plenty of performance. Durability will suffer, though; a crash might lose the state.
Of course, it's silly to recompute the entire game state for each client request, if the state did not change. You can cache the hard-to-compute common part and only recompute client-dependent parts, like 'fog of war'.
This leads us to the idea of a tiered database. Your most important things, like users' inventory or monetary balance, should be stored in a durable database, like Postrges or MongoDB. (BTW it's amazing what modern Postgres is capable of, and how fast writes to Mongo can be.) The often-changing things, like fog of war, positions of missiles in flight, etc, should live in a caching layer, something like Redis or Memcached, and only be stored to the durable store when an irreversible action happens (missile hits). The most important facts about the current game tick should be computed once and stored in the caching layer, in a form that allows easy queries and immediate sending to clients.
The state of the caching layer can be lost to a crash without catastrophic consequences, and can be recomputed from the durable data.
This is, of course, somehow complex. Don't go for it until you have a working crude prototype. Use only the durable store (e.g. Postgres) until you start hitting performance problems and have identified these problems to be database-related. Then you will see what to cache.