Во!

Это меня интересует в первую очередь, т.е. не серверу, а моему локальному компу не хватает каких-то ресурсов. Потому что на боевом сервере все отрабатывает довольно быстро, а на моем локальном компе, довольно медленно. Вот только не доразберусь я во всем этом, там целых 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, попал в точку