на самом деле тебе так кажеться : )) записываються цифорки по 4 байта локи унлоки всё это фигня база может работать если записываеться быстро, а потом начинаеться самое весёлое чтение фигня да хорошо а то что записать 4 байта даже с локами ему будет проше чем постоянно читать одни и те же текста с базы, и учитывая время я более чем уверен что там происходит что-то типо дай мне дроп, подожди какой дроп а давай закинем функцию SELECT * FROM .. LEFT JOIN .. .... ORDER BY RAND() "превед пацаны я не нагружаю чтения." если по русски. так что про чтения я не соглашусь, люди очень часто вешают на базу нагрузку которую могли бы не вешать подумав пару часиков над тем что они творят. записи легко сжать до минимума чтение гораздо сложнее.

Чето ты фигню пишешь. Локи вызывают очереди. Очереди увеличивают время записи. Время записи увеличивает время выполнения HTTP запроса, учитывая что в Хадде php, запросы выполняются не асинхронно, получаем timeout. А чтение - это просто чтение. При 200 игроках в чтение упереться сложно, ИМХО.
Сильно сомневаюсь, что дроп генерится в базе, скорее всего в php.

PS
На счет чтения и кэширования еще. Судя по всему МФы с вещей кэшируются куда-то, в persMe в main.php около wear лежит хэшик.

я ставлю на то что тут есть уйма прикольных mysql процедур функций и у mysql есть функция дай мне дроп : )). потому что это то как работали в тех годах, это то как проше работать.
если ты говориш про локи хорошо маладца давай посмотрим что будет по локам в 3 ситуациях.
1. insert into table tt (b,c,d) ('tt', 12, '12 is key field') > что сделает база заблочит тейб это вообше миг дальше закинит в конец таблички ну скажем 2-3 килобайта если всё сделано правельно даже при очень частых инсертах это не смертельно> ключь ну добавит ещё 50 байт в свои ключи. тут если много разнашорстных значений и значение падает где-то в середину и при том у него небыло раньше такого значения. может быть много памяти записано, потому что он построит это всё по возростанию. записали сняли лок всё впринципе тут не будет такого количество убер записей в идеале что-бы на 100 клиентах ламалась база данных, и покрывалась запретами, т.к. 1 запрос в среднем работает ну 200 милисикунд за 1 запрос ну максимум 20 записей, умножаем 20 * 5 = 100 записей в секунду от человека берём ещё 100 * 200 = 20 000 записей в секунду, переводим это всё в мегабайты, 3000 * 20 000 + 50 * 20 000 = 61 000 000 байт, 61 000 000 * 8 = 488 000 000 бит.

идём дальше
2.update.
тут первая стадия как правила работает с цифравыми значениями, и занимает ну 50 байт на запрос, т.к. память уже зарезервирована на стадии Insert. что у нас по ключям да тоже самое если ключи сушествуют это 50 бит если старый ключь был последний или новый он может по записям выдать больше, давай проведём прикодчную математику (и update на ключи очень редко проходит и как правило не вызывает ротацию по ключам.). 50 * 20 000 + 50 * 20 000 + 50 * 20 000 = 3 000 000 байт, 3 000 000 * 8 = 24 000 000 бит.
т.е. если чисто теоретически всё происходит примерно так то в обшем мы имеем 500 мегабит запись, при полном отсутсвии настроек mysql. обшее значение в теории сможет обеспечить 200 клиентов даже если будет висеть на жостком диске SATA 1 а это древний диск. и все локи будут быстро появляться и быстро проподать.

а вот теперь чтение.
3. 1. where clause.
ну тут всё довольно примитивно, забиваються ключи в память дёргаються постоянно (делая key level lock на запись или чтение по данному ключу пока он не закончит выборку, если нету ключа на время работы он закрывает всю табличку.).
в упдейт я писал что может пойти не так ну новый ключик появился цифорка стала выше если он падает где-то по середине.
что может пойти не так в where clause самая основная проблема это разростание таблиц допустим вы присоеденили 2-3 таблички и в одной из этих табличек 50 000 найденых записей во второй 20 000 в третей 1 (а может человек ошиьиться и будет не один не один). сколько нужно прочитать байт давай посчитаем,
4 байта ключик 50 000 * 4 + 20 000 * 4 + 1 = 280 000 байт, ну в битах можно сказать 2 мегабита, вообше нефига нету, согласен там больше математических операций. (и после каждого изменения ключа он будет снимать всё с кеша, так что вариант там есть mysql cache очень сомнительный.)

3. 2. order by clause.
тут у нас получаеться перевед медвед.
допустим в табличке 5 000 000 000 записей, (ну время прошло игра работала записывала.), отгодай сколько это выйдет в чтение ?
5 000 000 000 * на размер поля, при insert впринципе опять же будет сбиваться всё нафиг, берём теперь поле Int 4 байта
5 000 000 000 * 4 = 20 000 000 000 байта, ну я в биты даже переводить не стану тут уже понятно что жосткий не потянет без кеша. как будет работать кеш, новый инсерт относительно ключа превед у нас что-то поменялось начинаем читать всё заного, тобиш при очень большом количестве Insert кешируються только статичные таблички все динамичные работают почти в real time постоянно читая данные с жосткого диска, можно канешно построить это всё в оперативную память и будет проше, но факт останеться фактом чтения будет уйма и всё по желанию не закешируеш оперативки не хватит. так же как и в where clause работают запреты, на время пока он сортирует в нужном порядке все значения. не говоря о том что там ещё есть математическая часть которая будет опять же работать ещё дольше чем чтение с жостикх дисков.

т.е. вывод нужно уменьшить количество записей что-бы он не так часто ломал кеш. и постоянно не читал одно и тоже. ради повседневных задачь, возможно чисто теоретически это относиться к проблеме записей. но сама проблема не в записях а в чтении. те вещи которые я прикинул не уменьшат количество записей, но уменьшит количество чтений для выборки. т.к. сузиться интервал записей, с 3-4 секунд до 500-600 милисикунд.