Форум пользователей MySQL

rgbeast написал:

Сортировка идет по полю, которого нет среди группируемых полей, значит запрос некорректен с точки зрения SQL.

Разве? А я грешным делом всегда считал, что в таком случае MySQL сортирует по указанному полю записи внутри каждой группы и выдает первую. Иначе тогда непонятна идея оптимизации GROUP BY ... ORDER BY NULL

Ясно, спасибо )

Тем не менее в отличии от неправильного использования аггрегирующих функций, на такой запрос MySQL не ругается

1) Упростил запрос до:

Shopen написал:

1. Вы его слишком упростили. Это вообще уже совсем другой запрос. Записей мало (500) выбираются почти все (~350), индекс невыгодно использовать.

Упростите первоначальный запрос до функционального минимума, выбросте все SUM, уберите повторяющиеся LEFT JOIN и приведите его explain.

2. Нет, это значит надо запрос модифицировать. Нельзя сортировать по o_lastupdate, так как ее значение для каждой группы o_id неопределено. Т.е. чтобы сортирвать по o_lastupdate нужно чтобы это поле было передано через агреггирующую функцию:

SELECT o.id, MAX(o_lastupdate) AS max_update
FROM owners AS o
....
GROUP BY o.o_id
ORDER BY max_update DESC

1. Сделал такой запрос

SELECT o.*
FROM owners AS o
LEFT JOIN billboards AS b ON b.bb_owner = o.o_id AND b.bb_r NOT IN (...) 
LEFT JOIN prices AS price1 ON price1.p_bb_id = bb_id  AND price1.p_year = '2013' AND price1.p_month = '6'
WHERE
o.o_id IN (....)
GROUP BY o.o_id
ORDER BY o_lastupdate DESC

Выполняется за 0.9 сек.

А вот такой
SELECT o.*
FROM owners AS o
LEFT JOIN billboards AS b ON b.bb_owner = o.o_id AND b.bb_r NOT IN (...) 
WHERE
o.o_id IN (....)
GROUP BY o.o_id
ORDER BY o_lastupdate DESC

За 0.06

Explain 1 запроса:

id    select_type      table    type    possible_keys            key       key_len    ref    rows    Extra
1    SIMPLE        o             ALL    PRIMARY,565,o_id        NULL        NULL    NULL    417    Using where; Using temporary; Using filesort
                                                 ,viviv   
1    SIMPLE       b            ref    bb_owner,bb_r,           bb_owner    4      o.o_id  406    
                                                bb_owner_bb_r,
                                                bb_r_bb_deleted   

1    SIMPLE       price1    ref    p_year,p_month,         prices_bb_y_m_prices    7    b.bb_id,const,const    1    Using index
                                               prices_bb_y_m_prices   


Explain 2 запроса:

id    select_type    table      type    possible_keys    key               key_len           ref    rows    Extra
1    SIMPLE       o        ALL    PRIMARY,565,     NULL                NULL           NULL    417    Using where; Using temporary;
                                              o_id,viviv                                                                       Using filesort
1    SIMPLE       b         ref    bb_owner,bb_r,   bb_owner_bb_r    4         o.o_id    406    Using index
                                               bb_owner_bb_r,
                                              bb_r_bb_deleted   


То есть все упирается в медленной связке таблиц billboards(160к. записей) и prices(2 мил. записей).

2. Пробовал с MAX(o_lastupdate) AS max_update и ORDER BY max_update DESC. Особой разницы не заметил, если она и есть, то не существенна