Сколько себя помню пхп всегда так мог. Главное кавычки не перепутать :D . Когда тока начинал, бесило, что иногда не срабатывает :)

Ой Я вообще перешел на NoSQL (объектно-ориентированые) хранилища и очень доволен. Гибкость структуры как по мне просто колосальная. Но не будем заниматься лирикой.
- На самом деле на сколько я понимаю каждый из пользователей запускает этот скрипт, а результаты не всегда меняются. Да и необходимость в выборе всех данных я думаю тоже отсутствует, так как никто сразу не в силе просмотреть 2500 строк, все должно быть разделено на части (страницы) в случае просмотра информации.
- Проверять если ли пользователь в базе нужно однозначно на уровне базы с правильно выставленным ключем.
- Если у Вас запись вида id1, id2 ( то-есть 1 запись равно игра между двумя пользователями ) я бы сделал ключ по типу Math.min(id1,id2)+'.'+Math.max(id1,id2) таким способом генерируя валидный ключ, ну и можно после обернуть в md5 ( это в случае если Вам нужна выборка конкретной записи ).
- Так же я бы заменил тестовое поле "nomer_kryga" на числовое и записывал бы только число (текст уже подставлял во флеше).
- поля победитель и проигравший представлял в виде его ID, имя подтягивал бы вторым запросом. ( но предварительно выбрал все нужные мне айди и одним запросом выбрал их всех)
- Плюс ко всему я бы еще не использовал xml. На пхп клиенту отдавал бы данные
Что тоже бы немного освободило ресурсов как сервера так и интернет-канала.
- Да и передавал данные по amf-протоколу.

XML составлен избыточно неправильно и что мешает делать запросы к самому xml файлу?

Этот код диспатчит ошибку ;)
плюс, незачем в джейсон отдавать индексы
ну и желательно конечно сначала проверять, а будут ли вообще какие-то данные по запросу/
Или можно вообще url переменные отдавать вместо джейсона

Хех... ну, для начала, самое очевидное: возможно вам и нужно передать все 2500 записей из базы на клиент, но показать одновременно вы их не сможете никак. Даже на самых больших пользовательских мониторах у вас бы получилось по пикселу на строку, это если вертикально развернуть.
Отсюда вывод - показывайте понемногу. Более того, ни для MySQL, ни для PHP, ни для AS 2500 итераций в цикле - вообще не заметны. Но нарисовать на экране таблицу с таким количеством полей - тяжело.

Несколько замечаний по поводу связки PHP <-> AS. Во-первых, не используйте mysql_* группу функций ни для чего другого кроме какого-нибудь домашнего архива, который никому кроме вас не нужен. Эти функции передают строки серверу как есть, и это располагает к тому, чтобы злоумышленик передал с ними SQL код, который навредит базе данных. Посмотрите документацию по PDO, как альтернатива - mysqli - но PDO лучше, т.как это промышленный стандарт (более-менее), позволяет проще сменить базу данных, абстрагирует некоторые другие моменты в работе с БД. Не генрируйте XML склеиванием строк. В PHP есть сразу несколько классов которые это делают. Но, еще лучше - поищите библиотеку, которая реализует AMF формат. Это более комактный формат, тем не менее содержащий больше метаданных, чем XML, но он еще удобен тем, что он "родной" для Флеша.

Что касается SQL - пользоваться астерисками в запросах - лучше не нужно. Опять же, если задача одноразовая, то не страшно, но поддерживать код в котором поля таблицы не указаны явно очень сложно, уж поверьте... А еще лучше, возьмите книжку по базам данных, или недавно Станфордский университет проводил он-лайн курсы по базам данных. Там был базисный курс, который хорошо это объяснял. https://class2go.stanford.edu/db/Winter2013/preview/

Нагуглил SQLike as3

Я не пишу на PHP, но гугл предложил достаточно много полноценных ORM, с has_many из коробки и прочим.

ORM сам по себе не добродетель. PDO однозначно облегчает работу, его недостаток - нет возможности легально использовать какие-нибудь супер нестандартные фичи конкретной DBMS, например в MSSQL есть куча типов данных, но PDO должен поддерживать только те, которые есть и в MySQL и т.д.
ORM - это уже претензия на архитектуру. Предполагает специфическую структуру базы данных, обязывает к специфическому подходу к построению запросов. Кроме всего прочего, SQL - более выразительный язык, чем то, что можно представить через объекты и их свойства. Имитация сложных реляционных отношений в ОО может оказаться непосильным трудом / запутать.
Я видел как обычная авторизация сделаная наивно используя ORM делала более 50 запросов. Конечно, этот механизм в умелых руках может быть очень полезным, но если за него браться без опыта, то можно здорово попасть.

Честно, я не знаю, что такое PDO, но при беглом просмотре мне показалось, что это как раз ORM =)

Ладно, тогда просто объясню свою позицию в 3 словах: MDD – это хорошо.
Претензия на архитектуру... Отчасти соглашусь. По факту, он занимается тем что удобно для программиста делает запросы к БД и складывает результаты в сущности. Почти всегда это именно то, что пришлось бы сделать если этот запрос к БД происходит (конечно, речь о выборках). Сложно ли это в сложных ситуациях? Не настолько, чтобы отказываться от ORM, реализация которого обязана иметь возможность исполнения произвольного SQL-кода. Но с всеми защитами от хакера из коробки.
Никто не говорил о том, что владея какой-нибудь либой ORM сразу будут крутые приложения. Можно где угодно выполнять по запросу в цикле. Кстати, хорошие ORM'ы оснащены lazy-load'ом.
Я настаиваю на том, что ORM – абстракция от SQL у приложения, но не у программиста. Всегда нужно проверять что именно запросило БД у приложения просмотром сгенерированного SQL-кода. Зато если сначала сидели на РСУБД, потом перешли, например, на mongo, а потом решили сделать какие-то коллекции как "вшитые" (embed), то я на коне. И при этом я уверен, что у меня нет потенциальных дырок.

К слову, нормальный ORM должен поддерживать те типы, которые есть в языке.

Теоретически, да. Но на практике вряд ли, точнее не было критических ситуаций, хотя сложные выборки под хорошей нагрузкой присутствовали.

Скажите это тем, кто использует рельсы или джангу. Зато (назовем все это ORM) на себя берет из коробки львиную долю модельной логики, и не нужно париться о безопасности запросов.

для php уже придумано не хуже чем на ROR. Гуглите Yii ActiveRecord, Kohana ORM, symfony2 doctrine.

Сами используем для Python Джангу и для php Yii. Это очень хорошие штуки.