rPman

так?

SELECT user_id, name, MAX(points) as max_points
FROM `games`
GROUP BY user_id, name
ORDER BY max_points DESC
LIMIT 15;

Да, для хранения, добавления и чтения данных с анализом этот подход очень хорош, ценой незначительного для твоих объемов (кратного, Rsa97 все расписал) ты получишь огромный прирост производительности. Настоятельно рекомендую протестировать на тестовом стенде на своих данных, особенность хранения null записей в innodb и работа индесов с ними. Что лучше в твоем случае парный индекс в денормализованной форме или 200 индексов в нормальной можно будет определить только тестами (большая таблица может потребовать больше оперативной памяти на индексы).

Есть еще недостаток - если в таблице будет очень много данных, добавление и тем более удаление колонки будет проходить очень медленно, особенно если база данных в это время будет использоваться.

Ты забыл третий вариант, самый быстрый и наиболее предпочтительный если общее количество опций не велико (сотни, например у mysql лимит 1024 колонок максимум) - каждая опция это своя колонка, пустое (null) значение будет значить отсутствие опции у записи.

Недостаток подхода - если у объекта может быть несколько опций с одним именем, то такой подход не работает (но судя по всему это не твой случай).

Еще момент, полученная таблица будет сильно разряженной (т.е. много нулей) и многие базы данных на диске выделяют для пустых записей место (вопрос нужно изучать).

Если количество опций незначительно превышает лимит количества колонок - можно завести несколько таблиц. Так же это может решить проблему с разряженными таблицами, если грамотно раскидать часто используемые и редко используемые опции по разным таблицам.

p.s. если говорить про твои варианты:
* для 1 используй json сериализацию (опция=значение) в mysql для работы с такими данными есть соответствующие методы
* для 2 постарайся вместо текстовых наименований опций использовать числовые идентификаторы, заведя соответствующий классификатор либо в базе в отдельной таблице либо в виде констант в коде.

p.p.s. Ну и еще вариант, если тип значений опций - boolean (либо ограничен небольшим количеством значений, например цвет светофора 4 - выключен, красный, желтый, зеленый) то так же заводи для этих значений числовой эквивалент. В этом случае у тебя появляется еще бонус, упаковывать битовые значения (где количество вариантов 2^x и x это количество бит) и хранить в целочисленном поле сразу несколько (правда не все базы позволяют индексировать операции с битами).

Ты пытаешься список ключевых слов записать как одно значение, это нарушает идеологию работы с реляционными базами, правильно - у тебя должны быть таблица справочник ключевых слов (id,name) и таблица связей м-м (две колонки идентификаторы) между твой целевой таблицы и справочником (каждая запись в ней факт наличия ключевого слова. Соответственно запрос будет на наличие if exists или полсчет количества count или в зависимости от ситуации, проверка наличия связи по конкретному слову через left join и проверки результата на null.

P.s. если решать именно твоим способом, то у тебя должны быть 4 условия в or, проверки искомого слова слева like "слово,%", справа "%,слово" по середине "%,слово,%" и в единственном варианте ="слово"

P.s.s. у mysql есть поддержка работы с json сериализацией, храни тогда список слов в json

Полторы тысячи таблиц для innodb это мало и дополнительной нагрузки это не создаст (помню были какие то заморочки с myisam уже при количестве таблиц больше 100).

'очень частые' у разных людей разное значение, для кого то 1 раз в секунду - уже нереальная нагрузка, а кому то нужно 10к запросов в секунду обработать. Так вот во втором случае оптимизация будет требоваться уже на ином уровне и возможно 1500 таблиц станет заметно нагружать базу.

Задача не ясна, рекомендации невозможно дать.

Забудем что принципиально хранить пароли - плохая практика, но так как задача уже такова что хранение вынужденное то:
1. шифровать логины и пароли (весь набор данных, не имеющих смысл друг без друга, лучше хранить сериализованными в одном поле, особенно когда от задачи к задачи поля меняются, т.е. логин пароль почта api key, gpg ключи шифрования и т.п. пусть это будет свободная json строчка, за ее анализ отвечает клиентская часть приложения)
2. ключом/паролем, который не хранится в базе данных (он должен являться частью бакэнда, т.е. в том месте где на бакэнде хранятся настройки подключения к внутренним сервисам либо отдельное место хранения) - при разделении работ между людьми (обслуживать базы могут другие люди, чем те кто имеет доступ к бакэнду) чувствительные данные не утекут легко.
3. логируй все, т.е. показал пароль - сохрани в специальном логе (в базе или файлах уже вопрос организации работ) - кто, когда, с какой машины, что получил
4. когда показываешь пароль на клиентской машине, повторно запрашивай авторизацию (чтобы не использовалась автосохраненная), важный момент, это исключит кражу данных уже на стороне клиента, очень мало кто правильно организует рабочее место (это просто неудобно и дорого).

если нужно по каждой категории - добавь к запросу group by категория, в select будет sum(сумма) и категория

если выбор критерия вычисляемый, пропиши его формулу в select сумма as field_name ... group by field_name