[MySQL] выбор случайных записей

Это достаточно распространенное заблуждение, что если индекс строится по smallint (допустим), то он построится за доли секунды, какого-бы размера база не была.

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

С апдейтами ситуация немного другая, но в целом перегружать основную рабочую таблицу лишними индексами это очень плохая идея. Создатели mysql не зря придумали alter table disable keys и советуют его применять в ряде случаев.

Учитывает, если это надо и если правильно ее построить. В таких случаях просто добавляется дополнительное поле, по которому идет выборка. Если Вы обратите внимание на задачу ТС, такое всего одно и оно простое.

Кроме того, существует такая вещь как избыточность. Финальная фильтрация идет с учетом полных данных, но выборка по ней будет быстрой, т.к. основывается на ИД. Если нужно в результате 10 ИД, можно запросить 20, а если не хватит, то выдернуть еще.

Вы поймите основную мысль - она в том, что бы минимизировать размер таблицы по которой ведется выборка случайных ИД. Размер при чем в первую очередь физический. А дополнительная идея в том, что бы не дергать основную таблицу лишний раз.

Актуальность данных, если она нужна, должна гарантироваться не скриптом который строит доп.таблицу, а скриптом который делает выборку.

В практических задачах актуальность данных не всегда критична, но если она нужна, читайте выше про финальную фильтрацию.

Может Вы просто не вникали в суть тех, что предлагаются?

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

edogs Ну для начала я и не говорил про 2-гигабайтный таблицы (это обычно уже больше 10 миллионов записей - посмотрите с какими таблицами работает ТС). Индекс не является лишним, если он используется и имеет высокий Cardinality.

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

Актуальность данных должна гарантироваться не скриптом, делающим выборку, а наличием данных, которое обеспечивает скрипт генерации доп таблицы, т.к. именно по ней идет выборка. Я встречался с большим количеством практических реализаций и могу сказать, актуальность данных критична не так уж и редко. Если вы делаете маленькие простенькие проекты, тогда скорее всего очень часто не критична вовсе.

Решений есть соизмеримое - согласен. Я говорю о нормальном способе, а не о жутких генерациях дополнительных таблиц. Нормальное решение это когда у вас есть таблица, вы делаете ORDER BY RAND() и он отрабатывает за 0.002 сек почти на любого размера таблице вместо создания чего бы то нибыло по крону (без создания кучи файлов на жетском диске, без сохранения полугигабайта данных в мемкеше, без создания вспомогательных MEMORY таблиц и т.д.) - всё это решения под конкретную задачу - развитие инженерной мысли. Всем этим мне прихоилось пользоваться (в некоторых скриптах, которые отрабатывают и умирают у меня создаются MEMORY и TEMPTABLE таблицы, в некоторых строится дополнительная таблица с сетом данных, подходящих под выборку, в некоторых используются даже файлы). Так вот я о нормальном способе ORDER BY RAND() (нужное слово выделено) ;)

Если вы делаете маленькие простенькие проекты то Вы правы, тогда понятно откуда у Вас такие рассуждения. Однако в таком случае и обычный rand() не вызовет особых проблем:)

Тем не менее даже 256Мб-ная таблица не подарок в плане построения индексов или их частого апдейта, т.к. в результате Вы можете сэкономить на выборках меньше, чем потратить на индексы.

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

Если Вам нужна абсолютно 100% актуальность, то никто не мешает поддерживать кэширующую таблицу актуальной в реалтайме, параллельными запросами в нее, это один черт почти всегда будет быстрее, чем мучать большую рабочую таблицу с избыточными данными.

Никто не умаляет важности применения Вами этих решений, мы просто привели универсальное и стандартное решение, которое изрядно и предсказуемо облегчает задачу с минимальными кровопотерями.

И в этих случаях ее обеспечивает лишь реалтайм апдейт кэширующей таблицы или скрипт выборки проверяющий валидность выборки.

Мы именно об этом.

Нам кажется мы достаточно доступно объяснили о чем мы говорили, поэтому из топика откланиваемся что бы не скатываться в пустую дискуссию, если будут еще вопросы - обращайтесь в личку, ответим.