Оптимальней чем сортировать временную таблицу с предварительной записью этой таблицы с новым значением.
Да и про LIMIT в mysql советую прочитать. Работает он очень быстро, поскольку строки MySQL попросту пропускает не записывая в результат.
Напомню, топик был мною написан о том, как я нашел более производительное решение чем ORDER BY RAND(). Я ни в коем случае не утверждаю что мой вариант сравнится по скорости с нативной UDF процедурой MySQL. Я лишь говорю что это наиболее производительный вариант с обозначенными мною условиями.
Ну когда СУБД начнут говорить по человечески, то вполне возможны будут такие конструкции как «ВЫБЕРИ ЧТО-НИБУДЬ ИЗ ТАБЛИЦЫ БАННЕРОВ, ШТУК 10… ПОЖАЛУЙСТА :)»
А пока приходится искать нетривиальные решения и пользваться некрасивым кодом…
Вообще выборка произвольных записей — ресурсоемкий процесс. По моим тестам решение с UNION самое производительное на MySQL. Если владеете вопросом на достаточном уровне и располагаете более производительным решением — прошу поделиться :)
Ну тут интересно получается :)
Вопрос возникает вот какой — т.к. в лентах сграбленных кол-во итемов различается, то при честной равномерной выборке из всех итемов всех лент — чаще будут встречаться итемы из тех лент, где наполнение больше.
Если нужно чтоб вхождения из всех лент в результирующем наборе были по кол-ву равны, то можно сначала составить рандомный список лент, а потом из каждой выбрать рандомную запись в результирующий набор. Получится 10 записей из 10 разных лент.
Вопрос в легкости развертывания кода. PHP-скрипт — это drop-in решение. Да и в скорости работы не уступает нативному решению (я проверял, т.к. изначальный вариант был написан на C)
Во-первых, это лишняя операция и диск куда более медленное устройство чем память. Во-вторых, при описанной мной в топике нагрузке, файл будет очень быстро расти и его надо будет регулярно чистить. Все это лишние операции которые сильно усложнят схему работы.
Вариант вот какой — создать FIFO файл и на читающий конец повесить слушателя, который бы постоянно вычитывал оттуда записи в неблокирующем режиме в память (ту же самую FIFO очередь, но внутри памяти и не ограниченную лимитами система на FIFO файл), и в то же время писал бы эти данные в неблокирующем режиме из конца очереди в памяти сразу в файл. Получится что спокойно можно в несколько потоков писать в этот FIFO файл с другого конца применяя блокировки, поскольку вычитка с другого конца будет происходить моментально. Пример реализации (правда немного для других цели и с другой идеологией) можно подсмотреть в моей заметке о хитростяъх с логированием в однопоточных неблокирующих веб-серверахю
Да и про LIMIT в mysql советую прочитать. Работает он очень быстро, поскольку строки MySQL попросту пропускает не записывая в результат.
Напомню, топик был мною написан о том, как я нашел более производительное решение чем ORDER BY RAND(). Я ни в коем случае не утверждаю что мой вариант сравнится по скорости с нативной UDF процедурой MySQL. Я лишь говорю что это наиболее производительный вариант с обозначенными мною условиями.
А пока приходится искать нетривиальные решения и пользваться некрасивым кодом…
Вопрос возникает вот какой — т.к. в лентах сграбленных кол-во итемов различается, то при честной равномерной выборке из всех итемов всех лент — чаще будут встречаться итемы из тех лент, где наполнение больше.
Если нужно чтоб вхождения из всех лент в результирующем наборе были по кол-ву равны, то можно сначала составить рандомный список лент, а потом из каждой выбрать рандомную запись в результирующий набор. Получится 10 записей из 10 разных лент.