Serg434И при добавлении rand(), запрос начинает выполнятся по 4-6 сек, что не есть хорошо.Угу. В таком варианте при выполнении запроса к каждой записи таблицы на лету добавляется дополнительное поле, для него вызывается функция rand() и только потом производится сортировка записей по значению поля. Потому долго уже при не очень большом количестве записей.

Как один из вариантов, добавить поле и заполнить его рандомными значениями заблаговременно. Конечно, алгоритм выборки 4-х строк придется изменить. Например, что-то вроде "больше значения NNN, которое задано один раз рандомным числом".

miksoft,

Хороший вариант. Только стрелять 4 раза придется или формировать список из 4-х рандомных значений значений в IN. Фиг знает, что лучше. На большой таблице оно всяко лучше будет, чем WHERE `sort` > 123 ORDER BY `sort` LIMIT 4

Serg434Но идея в том, чтобы выдавать не популярные товары (для начала), а рандомные из наличия, тем самым увеличив ассортимент продаваемых товаров (если кто нибудь поиском не нашел)Может, ручками указывать для начала какие-то предлагаемые товары?
Будет статистика просмотров и покупок - можно её как-то дополнительно учесть. Но это ж сперва статистику делать надо.

Ну раз ручками не вариант, тогда статистику просмотров или продаж делать. Товары с популярностью выше некоторой (возможно, индивидуально установленной для каждой категории товаров) и отсутствующие в наличии/продаже не выдавать в предложения вовсе, а из остального рандомная выборка. Как вариант, конечно.

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

Serg434,

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

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

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

Serg434,

Давайте посмотрим, как это можно реализовать.

1 и 2 можно совместить, здесь в FAQ есть тема по нумерации строк. Другой вопрос, как много строк будет в выборке. Много строк - много времени уйдет. Вероятно, не так много, как в исходном варианте - счетчик работает быстрее чем rand(). Для однократного действия оно приемлемо, для формирования страницы сайта уже нет. Хранить эту выборку с пронумерованными строками придется в дополнительной таблице, скорее всего, ведь в п3 будут использованы номера строк.

Как вариант, дополнительную таблицу можно построить всего из двух полей - номер для выборки (автоинкрементное поле) и ID строки в основной таблице. Генерация таблицы связей быстрая получится, но при выборке потребуется JOIN и, как следствие, дополнительные ресурсы. Не интересно получается.

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

Serg434Если это так, то можно ли сделать вместо 2 и 3 пунктов, просто 4 выстрела в первый вариант?
Или как раз для этого и потребуется нумерация строк?
Есть столбец с айдишниками, но они будут не попорядкуВсё верно. Айди не следует использовать для этой цели, они другую задачу решают.
Первый и последний номера строк фиксируете где-то (редко изменяемые значения) и используете для генератора случайных чисел. Четыре числа - четыре выстрела.