[moka]

Много текста..

Для чата нужен real-time - это главное.
Следственно делать чат на PHP + MySQL - это как делать ММО на PHP, т.к. клиенту нужно будет постоянно спрашивать о сообщениях - AJAX. Постоянные HTTP запросы - не нужный overhead.
Это можно обойти Long Poll'ом или WebSocket'ами, но читай дальше.

PHP + MySQL. Как понимаю MySQL будет использоваться посредником для хранения данных и обменом между запросами к PHP. В любом случае PHP скрипту прийдется постоянно спамить MySQL на наличие новых сообщений. При каждом запросе от клиента или при фиксированном периоде если используется Long Poll или WebSockets подход.
Короче - постоянные запросы в огромные таблицы MySQL - просто не нужный overhead снова.

Как делается чат:
Начинается все только с real-time основы. Тебе нужно позаботиться о двух вещах:
1. real-time рассылка с минимальным overhead'ом.
2. Горизонтальное масштабирование, т.к. при больших нагрузках одного сервера тебе никогда не хватит.

1 - решается очень просто - не используй никаких посредников, а используй pub/sub паттерн, и при получении сразу рассылай клиентам которые подписаны на канал (комнаты), или шли напрямую на соединения (их может быть несколько), клиенту которому адресовано сообщение.

2 - сложнее. Тут у тебя может быть много процессов, с большим числом клиентов каждый. Тебе нужно сделать систему routing'а сообщений, т.к. иногда у тебя может оба общающихся клиента быть в одном процессе, а могут быть на разных. В таком случае нужно делать Routing систему, где сообщения будут толкаться серверам которым нужно пересылать сообщения. Использовать одну точку для messaging pub/sub, например redis - не смасштабируется при огромной нагрузки, но хватит на очень много. Рассматривай варианты где каждый сервер будет узнавать о разных изменениях стейтов клиентов, или использовать routing карту чтобы узнать списки серверов (может быть несколько снова), исходя из пользователя которому шлем или комнаты.
С комнатами лучше всех клиентов комнаты на одном сервере держать - так проще.
Также можно использовать MQ систему: RabbitMQ, ZeroMQ и т.п.

Только затем идет сохранение сообщений, и история.
"недавняя" история, типо последние 10 сообщений нужно держать в памяти все равно на серверах, чтобы избежать необходимости обращаться к базе данных при новых клиентах для получения недавних сообщений.
История отдельно сохраняется на сервере и никак не влияет на систему рассылок и т.п.

Далее тебе нужно будет позаботиться о push notifications системе. Учитывая что пользователь может быть на нескольких клиентах залогинен сразу (web и android например). А может быть и не одном из них.
Тут нужно быть окуратным. Если ты общаешься в web'е нормально, а на android у тебя клиент выключен, тебе не нужно слать push notification на android, т.к. пользователь уже прочитал сообщение в web'е.


Если честно, делать такое на PHP + MySQL это подход ранних 2000, это как делать ММО на PHP.
Не стоит.
Используй для этого подходящие инструменты: erlang, redis, cassandra.
Прототип чата на node.js + sockjs пишеться буквально за 20 минут.
Тебе не нужня реляционная база данных тут, лучше использоваь NoSQL который хорошо подходит к огромным объемам данных (чат - это много реал-тайм данных).

Также хранить историю переписки на серверах - учитывай что это весьма серъезное решение. Тут могут быть легальные и этические вопросы.