MySQL / PHP - Игра для веб-приложений - Спецификация пользователя c инвентарная таблица или 1 гигантская таблица? Другой вариант?

Question

Итак, я делаю веб-игру, похожую на Torn City, где потенциально могут быть миллионы пользователей. Моя проблема связана с инвентаризацией пользователей. Я начал создавать динамические c таблицы на основе идентификатора каждого пользователя. например, Имя таблицы = [ID пользователя] _Инвентарь. Из того, что я обнаружил, это может создать множество дружественных для хакеров записей с sql инъекциями и так далее из-за динамического создания c. Мой единственный другой вариант - создание 1 гигантского стола, содержащего каждый предмет, который есть у каждого игрока, и все различные детали каждого предмета. Похоже, что загрузка будет длиться дольше и дольше, когда число пользователей увеличится, и к инвентарю пользователя, вероятно, будут часто обращаться. Есть ли другой вариант? Моя единственная идея пока состоит в том, чтобы создать какой-то временный инвентарь, который бы захватывал только запасы активных игроков. Это помогает решить проблемы со временем поиска в базе данных, но все же возвращает меня к созданию динамических таблиц c. На данном этапе мне действительно не нужна помощь в кодировании, скорее мне нужна помощь по структуре базы данных. Код ценится, хотя. Приветствия.

Answer 1

Используйте большой стол. Индексируйте это оптимально. Это не должно доставлять вам хлопот, пока вы не пройдете миллиард строк.

Вот прием для оптимизации использования такой таблицы. Вместо

PRIMARY KEY(id),
INDEX(user_id)

есть

PRIMARY KEY(user_id, id),
INDEX(id)

Поскольку PK "кластеризован" с данными, а данные упорядочены в соответствии с PK, это приводит к тому, что все строки данных одного пользователя сидят рядом друг с другом. В больших таблицах это значительно сокращает число операций ввода-вывода и, следовательно, повышает общую скорость. Кроме того, это уменьшает давление на buffer_pool. (Я предполагаю, что вы используете InnoDB?)

INDEX(id) достаточно для AUTO_INCREMENT.

Могут быть и другие предложения, но мне нужно больше деталей. Пожалуйста, укажите SHOW CREATE TABLE (как оно есть сейчас) и основной SELECTs. Я, скорее всего, предложу внести дополнительные изменения в индексы, типы данных и формулировки запросов.

(таблицы Dynami c - ошибка, и ваши проблемы в этом направлении только начались.)