ms-dred,

1. пожалуйста, ставьте перевод строки перед каждым "AND"

2. поставьте слово EXPLAIN перед этим СКЛ и
выдайте результат сюда --- сразу будет понятно
сколько у вас записей и каких индексов (возможно)
нехватает.

3. суть запроса вполне ясна: вывести 4 статейки
которые связаны наибольшим количеством
обших тагов с данной статейки.

Начинается запрос с таблицы связок R -- найти все таги статьи 9056

AND r.r_wid='9056'

затем найти все похожие таги в таблице связок R2

AND r2.r_tid=r.r_tid

затем найти все статьи с этими тагами:

AND w.id = r2.r_wid

Дополинительные исловия и исключение оригинальной статьи:

w.public='1'
and w.added_at<'1379285739'
AND w.id!='9056'

затем группировка -- подсчет самых частво встречаемых
(т.е. повторяюшихся, т.е. имеюших много совпадаюших тагов)
стеек, сортировка и вывод первых четырех.

Диагноз -- или индексов нехватает или мускл не понял
с какой таблицы начать.

После того как вы выдадите ЕХПЛАЙН, можно будет посоветовать
индексы и/или добавить STRAIGHT для явного указания порадка
и/или переписать запрос --- например групировку, сортировку и лимит
лучше делать на втором этапе после подключения R2.

пардон, групировку и посчет можно делать на втором этапе,
но лимит 4 надо делать только
на третьем этапе после дополнительных условий на статьи.

ScareCrowавторДиагноз -- или индексов нехватает или мускл не понял
с какой таблицы начать.

вы смеетесь или издеваетесь?
диагноз - запрос кривой как бумеранг. аргументация - не все поля в кляузе group by

>> аргументация - не все поля в кляузе group by

и да и нет.

С точки зрения функциональности --
запрос абсолютно коректен -- это один из тех редких варинатов
когда неполный ГРОУП БУ допустим.

С точки зрения скорости --
да, вы скорее правы -- лучше сделать групировку и посчет на
втором этапе а не на третьем (как я сказал в предыдушем посте)

И самое главное -- человек попросил ускорить запрос.
Я подозреваю что исправлением индексов и/или
перестройкой запроса (например использованием СТРАЙТ)
можно будет получить более серьезный выигрыш чем
переносом группировки из третьего на второй этап.

Давайте подождем ресультатов експлейна а потом
дообсудим. Ибо лень гадать и тем более спорить не о чем ...

ms-dredавторEXPLAIN SELECT COUNT( w.id ) AS t_num, w . *
FROM w_table w, w_tag_relation r, w_tag_relation r2
WHERE w.public = '1'
AND w.added_at < '1379285739'
AND r.r_wid = '9056'
AND r2.r_tid = r.r_tid
AND w.id = r2.r_wid
AND w.id != '9056'
GROUP BY w.id
ORDER BY t_num DESC
LIMIT 0 , 4

ок, более менее понятно.
порадок прохода таблиц -- правильный.

надо создать индекс одиночный r_WID или
двойной R_WID_TID. Ваш сушествуюшик индекс
T_TID_WID подходит во воторой строчке EXPLAIN
но не подходит в первой строчке -- тут то и потерялась
скорость.

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

ms-dred,

ок , покажите результаты:

> SHOW CREATE TABLE w_table
> SHOW CREATE TABLE w_tag_relation

> select count(1) from w_table
> select count(1) cnt1,
count(distinct r_wid) cnt2,
count(distinct r_wid) cnt3
from w_tag_relation

> explain select * from w_tag_relation r where r.r_wid='9056'
> explain select * from w_tag_relation r where r.r_wid= 9056
> select count(1) from w_tag_relation r where r.r_wid='9056'

измерить скорость
> select * from w_tag_relation r where r.r_wid='9056'
> select * from w_tag_relation r, w_tag_relation r2,
where r.r_wid='9056'
and r2.r_tid=r.r_tid

на всекий сделайте еше OPTIMIZE TABLE

Все же покажите

> SHOW CREATE TABLE w_table
> SHOW CREATE TABLE w_tag_relation

Что-то у вас странное происходит. ЕКСПЛЕЙ дает
то ПРИМАРУ, то Т_ВИД индекс при поиске по R,
при этом всегда выдает 9 ROWS но иногда
filesort а иногда просто index.
При этом отличная милисекундная скорость.
Без поллитра и без SHOW CREATE не обойтись.


автор>select count(1) from w_table
выводит
count(1) 8479

ОК, нормально количество, не мало не много.


автор>select count(1) cnt1,
count(distinct r_wid) cnt2,
count(distinct r_wid) cnt3
from w_tag_relation
выводит
cnt1 cnt2 cnt3
76255 8495 8495

Ну примерно десяток статей на один таг. Нормально.

Тут я хотел посмотреь также р_ТИД , опечатался
...count(distinct r_tid) cnt3



автор> explain select * from w_tag_relation r where r.r_wid='9056'
> explain select * from w_tag_relation r where r.r_wid= 9056
Выводит, прикрепил снимком

Ок, но почему ПРИМАРИ??? илли он у вас,
дефакто, двойной (TID, WID)?
нужен SHOW CREATE TABLE !!!!!!!!!!!!!!!!

автор> select count(1) from w_tag_relation r where r.r_wid='9056'
count(1)
9

скорость запроса
> select * from w_tag_relation r where r.r_wid='9056'
0.0004


Отлично

авторскорость запроса
> select * from w_tag_relation r, w_tag_relation r2
where r.r_wid='9056'
and r2.r_tid=r.r_tid
0.0060

Отлично

теперь пойдем дальше:

Выдайте результат
>> select count(1) from w_tag_relation r, w_tag_relation r2
where r.r_wid='9056'
and r2.r_tid=r.r_tid

Выдайте результат
>> explain
select count(1) cnt, r2.wid
where r.r_wid='9056'
and r2.r_tid=r.r_tid
group by r2.wid

Выдайте скорость
>> select count(1) cnt, r2.wid
where r.r_wid='9056'
and r2.r_tid=r.r_tid
group by r2.wid

Выдайте результат
>> explain
select cnt, w.*
from
(
select count(1) cnt, r2.wid
where r.r_wid='9056'
and r2.r_tid=r.r_tid
and r2.wid !='9056'
group by r2.wid
) zz
STRAIGHT_JOIN w_table w
on w.public='1'
and w.added_at<'1379285739'
AND w.id = r2.r_wid



Выдайте скорость
>> select cnt, w.*
from
(
select count(1) cnt, r2.wid
where r.r_wid='9056'
and r2.r_tid=r.r_tid
and r2.wid !='9056'
group by r2.wid
) zz
STRAIGHT_JOIN w_table w
on w.public='1'
and w.added_at<'1379285739'
AND w.id = r2.r_wid

повторите два последних запросa (експлейн и скорость)
добавив в самом конце
... order by cnt desc
limit 0,4

ms-dred,

Нда, не ожидал такogo тормоза от mysql
при обработке неполного group by...
0.05 уже хорошая скорость (запрос ор MasterZiv)

Единствено что осталось проверить скорость:

иправьте везде на r_wid

ms-dred,

ну и шут с ним с этим запросом :-)
работает --и ладно.