rPman

Кодировка базы latin не предполагает хранение русских символов, по техническим причинам, соответственно коннектор понятия не имеет как твои символы корректно переводить в utf8.

Мало того, данные в базе как то оказались? В какой кодировке их туда помещали? Вот как помещал, так и извлекай

бинарные типы данных binary, varbinary или blob потому и бинарные, что к ним не применяются правила символьной трансляции (charset), т.е. к примеру их нельзя сортировать по алфавиту.

p.s. настоятельно рекомендую трижды подумать, зачем тебе нужно хранить изображения в базе данных, и с высокой вероятностью лучше их хранить в файлах на диске а в базе только имя файла (а можно и имена файлов привести к идентификаторам базы).

Тебе все ответили, тут два варианта - создавать в базе inmemory таблицу с одной колонкой и без индексов, и на ее основе уже делать

DELETE FROM A WHERE A.id NOT IN (SELECT id FROM B);

Либо написать скрипт, который выгрузит все id из базы, сравнит их (пока чисел не миллионы, это вообще не проблема) и сформирует список id которые нужно удалить (если всего 10к то их будет всего 3к), когда на десяток строк в любом языке программирования. Так как удаляются конкретные id то такой запрос будет работать быстрее чем delete where not in и возможно быстрее использования временной таблицы. Особых ограничений на количество id в where id in (...) я не нашел, если они есть то это проблема драйвера подключения к бд.

Есть еще третий вариант, который потребует изменения всего проекта, но заложит неплохие возможности. В базе данных нужно определить флаг - deleted (boolean), который устанавливать true если запись нужно удалить, это может быть дополнительное поле в каждой таблице где это имеет смысл, либо отдельная таблица (это эффективнее, если удаленные записи долго не нужно хранить) с единственным полем id, куда будут складываться идентификаторы записей на удаление. Естественно все запросы проекта нужно будет модифицировать с учетом этого поля/таблицы, чтобы пропускались записи, помеченные на удаление. Реальное же удаление проводить в момент наименьшей нагрузки на сервер или по другому критерию (например удаленные записи можно хранить для использования, к примеру отчетности). У метода есть подводные камни - например уникальные индексы/ограничения на другие поля нужно так же переделывать на сдвоенные с флагом удаленности, чтобы допускались записи с тем же значением что и удаленные.

так?

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 таблиц станет заметно нагружать базу.

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