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

P.S. Есть аналогичные запросы, основное отличие в использовании вместо таблицы read_stats другой и разве что меньшее количество строк(т.е. в read_stats могут просуммироватся данные до нескольких десятков тысяч строк, сотня тысяч, а в аналогичных запросах - несколько десятков, сотня). Т.е. может ли количество строк в данном случае замедлять запрос?? 

Конечно, у вас же помимо выборки еще умножение - деление удет...
Будет чуть-чуть быстрее, если o.percent/100)/1000 -> o.percent*0.000001

в смысле, вынести константу за вызов аргегирующей функции sum.
это раз.
заменить if на условие where + union.
или вообще на стороне клиента делать if.
как много строк в таблицах, на которые делается left join?

Не очень соображу как расписать запрос в таком виде.

т.е. в таблице read_stats хранится определенная статистика по книгам. У каждой книги может быть один или несколько авторов, что отражается в таблице ownership. Мне нужно получить статистику из таблицы read_stats для определенного автора, но если в эту статистику входят книги, где есть соавторы, нужно одной строкой получить и данные по тем статистическим данным, где есть соавторы.

Надеюсь не слишком запутанно 

Т.е. ownership(данные по конкретному автору) -> read_stats(статистика по книгам) -> ownership1(перебираю соавторов если они есть) ... и соотв. внизу группирую вся статистика для конкретного автора, и статистика для соавторов(часть статистика для конкретного автора)




В read_stats несколько миллионов наберется, а в остальных от нескольких сотен, до пару десятков тысяч(но это уже не много).

запрос 

может быть представлен в виде


почему же? 
у тебя же left join. значит, происходит практически перемножение.
т.е. результат будет порядка:
10^6 * 10^4 * 10^2 * 10^2 == 10^14
это даже не миллиарды записей.
и по ним ты делаешь группировку.... 
посмотри, сколько записей у тебя возвращает запрос без "group by"

skyboy, Нет, нет, нет



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

Но это еще не все. 



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

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

Разве это рабочий запрос? Ведь выделенные красным поля не включены в Group by

не надо делать так

надо делать так:

дамп структуры БД и хранимку, которая заполняла бы БД рандомными значениями можешь выложить?

Я делал и так, и так. Все равно довольно медленно 



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



ТоляМБА, "политика" такая.  Если бы она была чуть иная, скорее всего с медленно работающими запросами, у которых хороший explain я бы вряд ли столкнулся. 

мягко говоря, не хватает таблицы persons.
и хоть по 2-3 записи на таблицу.

сорри




А вот записи, реальные на вряд ли. 

нафиг мне реальные данные?
во все текстовые поля запихни один символ(произвольный).
timestamp - рандомное число.
не заниматься же мне ещё и анализом структуры БД, чтоб заполнить хотя бы десятком записей с корректными значениями, верно?

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

ТоляМБА, совершенно верное замечание. Хоть MySQL и не выдает ошибку, выборка полей не сгруппированных и не использующих агрегатные функции - полностью бессмысленна и непредсказуема.

Bulat, попробуйте постепенно упрощать запрос, убирая по одному элементу из запроса. 
Так же выполните запрос SHOW STATUS, возможно серверу просто не хватает места для кеширования всех индексов, используемых в запросе. Попробуйте поиграться с параметрами сервера Tuning Server Parameters и InnoDB Performance Tuning Tips

sTa1kEr, в случае с двумя запросами уходит одна из группировок как раз по этому  результату "атомарной логической операции". так что даже не знаю...

Добавлено через 1 минуту и 11 секунд

если есть вариант: подзапрос или union что выберешь ты?
кстати говоря, индекс применяется при использовании функции(оператора) if?

Прошу прощенья, не заметил группировку. В этом случае, я думаю, будет по сути примерно одно и тоже.

При чем тут подзапрос? Я имел ввиду то, что операция if() сама по себе ничего не стоит.

Какой индекс в поле выборки?