если нужно получить 10 случайных записей: [sql]SELECT quote FROM quotes WHERE id IN (100 случайных чисел через запятую) LIMIT 10[/sql]
там про 2 запроса. Первый SELECT id => получаем массив id (плотный) и его длинну ~3953 рандомим 0, 3952 берем нужный. В обще говориться что это быстрее, хоть и два запроса... Гугль нормально переводит сайты, когда лень самому напрягаться!
mysql_fetch_array читает результат запроса по строчке подскажите функцию, которая получает результат выполнения запроса сразу в масив
PHP: $sql_plus_films=mysql_query("select * from films order by rand() limit 20"); (3+ сек.) получается быстрее чем PHP: $count_ids=mysql_num_rows($sql_ids=mysql_query("select id from films ")); for ($c=0;$c<$count_ids;$c++) { $array_ids[] = mysql_fetch_array($sql_ids); } $sql_plus_films=mysql_query("select * from films where id in (".join(",",array_rand($array_ids,20)).")"); (4+ сек.)
joost, а ты попробуй таблицу на 400 000 записей хотя-бы, как на БашОрге Дело в том, что ОрдерБайРенд - перед выполнением запроса во всех строках таблицы вставляет случайное значение
еще одна попытка: дополнительно иметь поле непрерывных ид. при удалении н записей переписывать н максимальных ид на удаленные (обработать удаление максимальных) выборка идет пыхом Х случайных значений из плотного набора и where r_id in()
любопытно. но недостаток - тот же, что у предыдущего. если у меня 100 записей, а ид начинаются с 101...
Так там не count, а max. Если 100 записей и id начинается с 101, то максимальный id будет 201. Для выборки id будут задаваться в диапазоне 1-201.
Ну, там в статье идет речь о средней распределённости. Даже в этом случае вернуться все 10 записей, просто запросы будут сыпаться до тех пор, пока результатов не наберется нужное количество.
Кстати по доборному методу. Зачем в следующем запросе уменьшать число генерируемых значений? И почему бы скажет генерировать не 10, а 20 или ещё больше значений? Тогда вероятность того, что среди них окажется 10 существующих больше чем вероятность того, что 10 существующих окажется среди 10 выбранных. По моему выбрав лишние записи мы много не потеряем.
Да, действительно. Тогда количество запросов можно уменьшить. Спасибо, поправлю. Ну да, у меня же общее решение. Для такой распределенности нужно писать что-то свое.