Об оперативной разумеется)
В общем возвразаясь к теме первого вопроса. 100 запросов в секунду при работе с проиндексированной таблицей - это не много. Но в целом, затрагивая вопрос архитектуры игры - такой подход не правильный.

А чем он неправильный?)) Я просто не пойму. Вот человек играет. Собирает одну монетку, посылаем запрос из флешки, серверу. Сервер же обрабатываем полученные данные и делает запрос в бд, дабы записать, что вот этот игрок собрал одну монетку и если он сейчас выйдет из игры, покинет браузер и вернется на следующий день, то у него будет та самая монетка, которую он вчера получил) В чем неправильность?) Ну будет не один, а 500 таких игроков, которые собирают монетки, 500 запросов в в бд и то не факт что в секунду, кто-то может в это время не собирать монетки, а заниматься чем-то другим. Как будет правильно тогда?)

Хорошо, для игры где нужно кликать по монетками - это подходит идеально)
Для более сложных игр - нет. Если приведете пример более реальной игры - объясню чем.
Для любой игры где нужен мультиплеер - ваш вариант не подходит.

А чем эта игра не реальная? В любой игре, используются одни и те же запросы в БД. Select, insert, update - основные запросы. Они не куда не денутся в другой игре) К примеру, давай возьмем такую игру. Есть чувак, который переходит по локациям, каждая локация имеет свой уникальный id, соответственно при переходе в другую локацию - update в одну таблицы и insert в другую. К примеру, в каждой локации есть монеты, которые игрок может собрать. При сборе монеты update одной таблицы, insert в другую. Помимо всего прочего, персонаж может нарваться на неприятности, например на него кто-то напал неведомый. Опять же идет запрос в бд, мол этот игрок вступил в бой и чтобы когда он вышел/вернулся в игру, то мог продолжить бой. В бою также, при каждом ударе идет запрос в бд, чтобы отслеживать сколько осталось хитов у оппонентов и тп, при этом запросы не к одной таблице, а к нескольким. К примеру. Объясняй)

Странно вы как то выделяете сущности.. Почему локация таблица в которую инсертится игрок?
Таблица локаций может представлять собой id, name, preview, background, walls
Таблица игрока id, currentLocationId, coins
При переходе игроков на локацию будет апдейтится поле в его таблице. Это что касается вашего примера.
Я еще раз говорю, он имеет право быть. Но представьте что у вас на локации другие живые игроки. как вы будете узновать их координаты? Опрашивать базу каждую секунду?
Игра может иметь сложные состояния, не все из которых можно представить в виде таблиц.

Поднимаете сокет-сервер на php. Клиент коннектится, собирает монетку, вы в оперативной памяти в переменной состояния типа coins_amount делаете инкремент. Когда клиент отваливается (пропадает инет, или пользователь закрывает браузер), сервер ловит это событие и по нему записывает переменную в базу, либо делает это по другому событию. Таким образом, у вас не будет дергания базы на каждый клик.

Чем плохо дергать базу каждый клик. Во-первых, если есть возможность этого не делать, то зачем нагружать базу лишними запросами. Во-вторых, 500 запросов в бд в секунду не так уж и много, но мы же все хорошие программисты и сразу пишем под хайлоад :) В-третьих, не хотите поднимать сокет-сервер, используйте для хранения монеток redis, и синхронизируйте раз в час собранные им данные в базу.

Добавлено через 1 минуту
как раз таки в любой нормальной игре на каждый пук от клиента база не дергается, всё хранится в оперативной памяти в переменных состояния и сохраняется в бд только по определенным событиям.

А у вас есть пример реализации? И где гарантия того, что к примеру читер не изменит значение переменной сoins_amount и когда придет время отправки в бд запись, то там не будет триллион монет)

как он изменит coins_amount в оперативнйо памяти сервера?
Практически каждая игра топа вк - пример такой реализации

Ладно, а есть документации какие-нибудь по такой реализации? Ибо пока я еще не особо понял, как это применять на деле.

Можно и "как бы" писать в базу, а для кэширования использовать memcached