В чем могут быть причины медленного выполнения запроса, если 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() сама по себе ничего не стоит.

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

Во!

Это меня интересует в первую очередь, т.е. не серверу, а моему локальному компу не хватает каких-то ресурсов. Потому что на боевом сервере все отрабатывает довольно быстро, а на моем локальном компе, довольно медленно. Вот только не доразберусь я во всем этом, там целых 245 строк. Может что поконкретнее show status like '?' ?? 

вот-вот.
по результату сравнения в if выбирается константное значение поля выборки(1 или 0). индексы по сравниваемым полям не используются.
или это же сравнение происходит в секции where(в случае использования union), что не обязано ускорить выполнение, но допускает использование индекса по полям o.person и ol.person(которые сравниваются). я ошибаюсь?

да, ничего. тем более, не во всех запросах она почему-то фигурирует: сразу была, потом без неё работаем, потом - снова всплыла...

ну, я же не знал, что ты не видел группировку. хотел вот намекнуть, что не всегда простая операция столь незначительна(пожалуй, с подзапросом слишком "простая" и "далекая" аналогия; ни в коей мере не хотел оскорбить). так же, как и умножение(или деление), которое выполняется внутри агрегирующей функции - вроде мелочь, но в случае нескольких миллионов записей уже как бы и не мелочь...

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

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

Вот да, кстати, все не досуг было проверить, а любопытно....

ТС, что быстрее будет отрабатывать? SUM(a * b * c) Или просто SUM(a), SUM(b), SUM© 
а затем уже перемножаем локально...

в задаче о Bulat'a стоит вопрос по-другому: если каждое значение умножать на число(0,0001), а потом пытаться суммировать - догадается ли оптимизатор сначала все посуммировать, а потом уже умножить полученную сумму? я бы не полагался на оптимизатор в таких тонсостях...

Уточняю 

Я спрашивал про вот это

Fortop, сумма произведений и произведение сумм - далеко не одно и то же: 2*3*4 + 2*3*4 != (2 + 2) * (3 + 3) * (4 + 4). тут уже никак не разделишь(не считая вырожденных случаев, когда один из множителей - 0 и тому подобных редких крайностей)

 знаю, но меня интересует именно скорость работы.

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

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


Я думаю без разницы. Во всяком случае в реальной жизни нужно думать не о количестве арифметических операций, а о точности и корректности вычислений. К примеру sum(rs.hits * rs.price * o.percent) и sum(rs.hits) * avg(rs.price) * avg(o.percent), может быть второй вариант и быстрее на несколько миллисекунд, но вот точность вычислений явно при этом страдает.


Для начала стоит обратить пристальное внимание на:
Innodb_buffer_pool_reads, Innodb_buffer_pool_wait_free - в идеале должны равняться нулю.
Key_reads - должно быть значительно меньше чем Key_read_requests
Created_tmp_disk_tables - в идеале должно равняться нулю
Opened_tables - так же чем меньше - тем лучше

Это сообщение отредактировал(а) sTa1kEr - 23.7.2008, 07:48

А если не в идеале





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

Это сообщение отредактировал(а) Bulat - 23.7.2008, 09:32

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

Задумайтесь о том, чем в этот момент занимается mysqld. Сначала ему надо прочитать все это, потом ему надо сделать выборку, потом составить из результатов что-то, выглядящее более-менее логично согласно JOINам. Естественно, что время выполнения запроса зависит от кол-ва рядов.

Очень может быть 

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

говорят о том, что все таки стоит попробовать уведичить пул. 
Попробуйте увеличить значение innodb_buffer_pool_size.

Ок, возьму на заметку.

Но похоже MuToGeN, попал в точку