Это у тебя не один, а два запроса. Глядится неплохо. А по скорости - можешь сам замерить. Только на более менее больших данных. Сравни например с таким:

$res = mysql_query("SELECT * FROM `table` ORDER BY RAND() LIMIT 1");

Michael
Твой вариант медленнее.

Michael
Да, two дело говорит. Действительно быстрее. На себе попробовал. Таблица ~2млн, по твоему запросу - 23.1759 сек. А метод two 0.8858 сек

Michael
Ну смотри:

1'000

0.00505518913

0.00125408173

10'000

0.0912001133

0.00746798515

100'000

0.61438584328

0.0475871563

500'000

21.3207550049

1.58239793777

1'000'000

72.680314064

1.64496612549

Подведу итоги самостоятельно:

Вариант с RAND() можно использовать в таблице до 100 записей. В ином случае намного быстрее будет мой вариант.

Нашел еще один сбособ:

$range_result = mysql_query("SELECT MAX(`id`) AS max_id , MIN(`id`) AS min_id FROM `table`");
$range_row = mysql_fetch_object($range_result); 
$random = mt_rand($range_row->min_id, $range_row->max_id);
$result = mysql_query("SELECT * FROM `table` WHERE `id` >= $random LIMIT 0,1 ");
$us = mysql_fetch_assoc($result);

Он быстрее моего, хотя при сравнении их пишут, что он медленнее. Проверьте кто-нибудь скорость :)

Если ты серьёзно этим озабочен, значит ожидаешь большую посещаемость, правильно? Так вот. При больших нагрузках не столь важна скорость выполнения скрипта, сколько скорость выполнения отдельных запросов. Тоесть мерять нужно их.

Поясню. Допустим мы проектируем макдональдс. И ожидаем большой наплыв посетителей. Для этого у нас есть помещение (PHP) и несколько точек раздачи (MySql). Не совсем правильно расчитывать пропускную способность, меряя скорость употребления пирожка каждым посетителем. Гораздо важнее знать расторопность продовца и количество покуаемых гамбургеров. Если продавцы справляются с потоком посетителей, то все хорошо. Выдали побыстрому ему бомж-ланч, и пусть себе мирно кушает в уголочке хоть полчаса. Места много. А если продавец будет по часу возится с каждым, то на выдаче будет очередь, а помещение будет простаивать.

Так и тут. Не так важно, сколько времени молотит процесс php. Важно быстренько выдать ему результат и заняться следующим, чтобы очередь не копилась.

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

$range_result = mysql_query("SELECT MAX(`id`) AS max_id FROM `table`");
$range_row = mysql_fetch_object($range_result); 
$random = mt_rand(0, $range_row->max_id);
$result = mysql_query("SELECT * FROM `table` WHERE `id` >= $random LIMIT 0,1 ");
$us = mysql_fetch_assoc($result);

Минус этого метода

$range_result = mysql_query("SELECT MAX(`id`) AS max_id FROM `table`");
$range_row = mysql_fetch_object($range_result); 
$random = mt_rand(0, $range_row->max_id);
$result = mysql_query("SELECT * FROM `table` WHERE `id` >= $random LIMIT 0,1 ");
$us = mysql_fetch_assoc($result);

заключается в том, что значения в поле `id` не всегда распределено равномерно и без "дырок". При удалении записей "дырки" будут появляться, а значит есть вероятность попасть в них.

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

id
1
2
3
1000

значения в таблице притянуты за уши, но это как раз выражение возможного частного. На граничных, "странных" вариантах проверять начинаем.
Анализируем как на этой таблице будет работать вариант с MAX(id)
Случайное число $random будет постоянно бить между 3 до 1000, это очевидно.
Значит под `id` >= $random будет выдавать постоянно id==1000, что не верно, т.к. все 4 записи должны быть равнозначны.
Т.е. в этом частном случае алгоритм не верен.
А значит и в общем (для любой возможной таблицы) - тоже.

Ну вот почему я и написал про нижний предел.

twin
Да-да, теперь заметил.

twin
Всё равно дыры присутствуют =(