netwind

Именно. Если это редко вызываемый статистический запрос, то почему бы не попробовать?

процедуры и переменные сгенерируют точно такую же же нагрузку на mysql, лишь немного облегчат затраты на парсинг запросов.

Кстати, что вообще вы собираетесь потом делать с таблицей в 1000 строк ?

неужели пользователю выводить?

malls, не понимаю причем тут память php ? ну 200 записей из первой таблицы полежат в памяти.

ой да. так не получится, зато получится выбрать ид записей в second и прилепить их через where in ().

однако у меня такой запрос в mysql 5.0 выдает

ERROR 1235 (42000): This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'

так что все гораздо хуже.

Получается проще на php в цикле. Иначе придется изучать процедуры и курсоры в mysql.

объединять с подзапросом разве что .

select first.*,second.data

from first, (select data from second where id_first =first.id limit 5) as second

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

netwind добавил 24.02.2009 в 19:04

Как-то так. таблицы я приблизительно воссоздал.

select ud_feed_rwd_users.*,innertab.clicks_count as clicks_count,COUNT(ud_feed_searches.id) as searches_count
     from  (
        select pid,count(ud_feed_clicks.id) as clicks_count
        from ud_feed_clicks
        group by pid
        order by clicks_count desc limit 0,10 )
     as innertab, ud_feed_rwd_users, ud_feed_searches
where
ud_feed_rwd_users.id=innertab.pid and ud_feed_rwd_users.id=ud_feed_searches.pid
group by ud_feed_rwd_users.id;

у меня тут query_cost вышел вообще 0 против 7.92 :) надо данных закидать генератором и проверить.

+----+-------------+-------------------+--------+---------------+---------+---------+-------+------+---------------------------------+
| id | select_type | table             | type   | possible_keys | key     | key_len | ref   | rows | Extra                           |
+----+-------------+-------------------+--------+---------------+---------+---------+-------+------+---------------------------------+
|  1 | PRIMARY     | <derived2>        | system | NULL          | NULL    | NULL    | NULL  |    1 |                                 | 
|  1 | PRIMARY     | ud_feed_rwd_users | const  | PRIMARY       | PRIMARY | 4       | const |    1 |                                 | 
|  1 | PRIMARY     | ud_feed_searches  | ref    | pid           | pid     | 5       | const |    4 | Using where                     | 
|  2 | DERIVED     | ud_feed_clicks    | ALL    | NULL          | NULL    | NULL    | NULL  |    2 | Using temporary; Using filesort | 
+----+-------------+-------------------+--------+---------------+---------+---------+-------+------+---------------------------------+

от полного сканирования clicks это не избавляет. нужны или дополнительные таблички для агрегированных данных или ограничивать под дате.

Непонятно какой смысл вы здесь вкладываете в distinct ?

вряд ли ud_feed_clicks.id и ud_feed_searches.id содержат неуникальные значения и, я думаю, mysql сам догадается не тупить, но все равно лучше disctinct убрать.

seolancer, озвучьте серийники что-ли без последних нескольких цифр. А то присматриваю тоже.

И лучше по этому вопросу где-нибудь на ixbt поинтересоваться. Там сервисные инженеры чаще бывают

Опять удаление аппендицита по переписке? Почему вы думаете, что это вам даст возможность решать проблемы с сервером в будущем? Не даст.

Эти команды показали что dns работает - этот надрез был не туда.

malls, cнова бредите (противоречите сами себе ) .

просто запишите не списком с комментариями, а в терминах логических отношений и запрос сам напишется.

как это все понимать ?

я понимаю ваш список как (п.1 ) И (п.2) И (п.3) . первый вася всем трем условиям не удовлетворяет, но вы пишите, что первый вася вам нужен.

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

Если зафиксируете проблему более традиционными методиками, может даже зашевелятся.