РЭНД ORDER BY () альтернатива [дубликат]
в ответ на ответ mattlant - sharepoint будет работать хорошо управлением версиями, только если функция управления версиями включена в библиотеке документа. кроме того, знайте, что любой код, который называет другие файлы работой привычки относительных путей. и наконец любые ссылки на внешние файлы повредятся, когда файл будет сохранен в sharepoint.
9 ответов
Я думаю, что лучший способ - загрузить идентификаторы продуктов на средний уровень, выбрать случайные 40 значений, когда вам нужно (один раз в час или для каждого запроса), и использовать их в запросе: product_id в (@ id_1, @ id_2, ..., @ id_40) .
Не сражайтесь с кешем - разоблачите его!
Напишите свой запрос таким, какой вы есть (или даже проще). Затем в своем коде кешируйте результаты, задав срок действия кеша на 1 час. Если вы используете слой кеширования, например memcached, все готово. Если нет, вы можете создать довольно простой:
[pseudocode]
global cache[24]
h = Time.hour
if (cache[h] == null) {
cache[h] = .. run your query
}
return cache[h];
Если вам нужен новый набор случайных данных только один раз в час, не обращайтесь к базе данных - сохраните результаты на уровне кэширования вашего приложения (или, если его нет, просто поместите его во временный файл какого-нибудь). Кэш запросов удобен, но если вам даже не нужно выполнять запрос, еще лучше ...
Если у вас есть столбец идентификатора, лучше выполнить следующее:
-- create a variable to hold the random number
SET @rownum := SELECT count(*) FROM table;
SET @row := (SELECT CEIL((rand() * @rownum));
-- use the random number to select on the id column
SELECT * from tablle WHERE id = @row;
Логика выбора случайного идентификатора число можно переместить на уровень приложения.
SELECT * FROM table ORDER BY RAND LIMIT 40
очень неэффективно, потому что MySQL будет обрабатывать ВСЕ записи в таблице, выполняя полное сканирование таблицы по всем строкам, упорядочивая их случайным образом.
Он уничтожит кеш, потому что вы ожидаете каждый раз другого набора результатов. Невозможно кэшировать случайный набор значений. Если вы хотите кэшировать группу результатов, кешируйте большой случайный набор значений, а затем в подсекциях времени, когда вы собираетесь использовать эти значения, выполните случайный захват в меньшем наборе [вне sql].
у вас может быть столбец со случайными значениями, который вы обновляете каждый час.
Один из способов добиться этого - перетасовать объекты, которым вы сопоставляете данные. Если вы не сопоставляете данные с объектами, вы можете перетасовать массив результатов из базы данных. Я не знаю, будет ли это работать лучше или нет, но вы, по крайней мере, получите преимущества от кеша запросов, о котором вы упомянули.
Вы также можете сгенерировать случайную последовательность от 1 до n и проиндексировать результирующий массив (или массив объектов) с их помощью.
вычислить текущий час в коде PHP и передать его в запрос. это приведет к статическому значению, которое можно кэшировать.
обратите внимание, что у вас также может быть скрытая ошибка. поскольку вы берете только час, у вас есть только 24 различных значения, которые будут повторяться каждый день. Это означает, что то, что отображается сегодня в 13:00, будет таким же, как то, что будет показано завтра в 6. Вы можете это изменить.
Это будет очень неприятный запрос, если ему нужно отсортировать большой набор данных в случайном порядке (что действительно требует сортировки), а затем отбросить все, кроме первого 40 записей.
Лучшим решением было бы просто выбрать 40 случайных записей. Есть много способов сделать это, и обычно это зависит от равномерно распределенных ключей.
Другой вариант - выбрать 40 случайных записей в пакетном задании, которое выполняется только один раз в час (или что-то еще), а затем запомнить, какие именно.