tanglirokuznetsovВ результате получились два запросамне кажется или это один и тот же запрос, только с изменённым порядком таблиц в джойне?
okuznetsov 1) Также хотелось бы узнать можно ли что-то сделать и с этим запросом: Скорее всего нет. Ордер бай ранд() работает дубово: выбирается всё, подходящее под условие, для каждой записи генерируется рандом, результат сортируется. Учитывая, что сортировать надо практически всю таблицу (если ид у вас - ПК), то сортировка запросто может задействовать диск. Превед производительность.

А запросы к инфо_схема и не обязаны быть быстрыми. Неужели вам требуется выполнять их N раз в секунду?

1) Именно так, один и тот же запрос, оформленный по разному. вроде бы по скорости одинаково выполняются. по стилю написания, т.е. хорошему тону какой соответствует?

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

Меня устраивает и следующий вариант реализации. Если вот таким образом сделать - это хорошее решение?

авторSELECT *
FROM game AS r1
JOIN
(
SELECT (RAND() * (SELECT MAX(id) FROM game)) AS id
) AS r2
WHERE r1.id >= r2.id
#ORDER BY r1.id ASC
LIMIT 15;

Расшифровка (на всякий случай):

JOIN добавляет все ID который больше или равны нашему случайному значению и мы выбираем ближайшего соседа, если равенство не возможно. НО как только 15 строк найдено мы останавливаемся.

А в чём плохая реализация заключается? По времени на моей таблице в 7 000 000 строк запрос стал выполняться достаточно быстро - в пределах от 0.040 - 0.080 сек, на порядок ускорился.

Вариант предложенный вами сейчас тоже изучу

javajdbcokuznetsovА в чём плохая реализация заключается? По времени на моей таблице в 7 000 000 строк запрос стал выполняться достаточно быстро - в пределах от 0.040 - 0.080 сек, на порядок ускорился.

Ваш вариант выбирате 15 ид подряд начиная
с некоторого случайного числа.
Если это и есть ваше определение 15 случайных ИД --
то ок.

Мой варинат -- 15 реально случайно разбросаных ид

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

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

Если с моим запросом всё в порядке тогда беру его)

javajdbcokuznetsovА в чём плохая реализация заключается? По времени на моей таблице в 7 000 000 строк запрос стал выполняться достаточно быстро - в пределах от 0.040 - 0.080 сек, на порядок ускорился.

Ваш вариант выбирате 15 ид подряд начиная
с некоторого случайного числа.
Если это и есть ваше определение 15 случайных ИД --
то ок.

Мой варинат -- 15 реально случайно разбросаных ид



Можете помочь мне вот с этим запросом разобраться? Я не знаю и не понимаю пока для чего и зачем он нужен, но он в моём списке медленных запросов mysql-slow.log:

2) И хотелось бы что-то сделать с запросом такого плана (primary key соответственно в данной таблице нет):


авторselect ifnull(sum(data_length + index_length), 0) from information_schema.tables where table_schema = 'dbgwg';



выполняется в среднем около 0.5 сек в среднем бывают моменты когда более 1 секунды

EXPLAIN EXTENDED следующий:

1 SIMPLE tables ALL TABLE_SCHEMA Using where; Open_full_table; Scanned 1 database

поправленный вами вариант, заработал, вижу стали генерироваться разные ИД, но скорость выполнения запроса упала в разы, на моей таблице составляет от 0.5 - 1 сек, это много. в том варианте который у javajdbc и менят- запрос выполняется от 0.040-0.100 сек.

спасибо за объяснение "Считает размер таблиц в схеме 'dbgwg'. По идее, чисто админская операция."

tanglirКстати, вы несколько раз проверяли? у меня стабильно за 0,05с отрабатывает, только первый запуск был 0,2с.

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

а как вместе - я заснял для вас здесь -

okuznetsov,

лучше на ютьюбе посмотрите, перейдите по прямой ссылке _

okuznetsov,
курсор мышки нужно было просто убрать:) и не чего не отрезалось бы:) заработался)