Mysql performance

[Demetros]

Вы слышали о using/force index? После вас читать такие запросы и ломать голову, откуда и зачем здесь object+0=0 — занятие для стойких духом.

[Casus]

А вы внимательно прочли топик?
«Используемые «хитрости» работают также на PostgreSQL, Oracle, SQLite, DB2 и не являются MySQL направленными»

[2fast4rabbit]

Поддерживаю Demetros-а, надо учить матчасть а не огороды городить.
dev.mysql.com/doc/refman/5.0/en/index-hints.html

P.S.: А вы внимательно прочли топик?
«Mysql performance»

[Casus]

Извините конечно, но я считаю ваши комментарии неуместными.
1. Я отчётливо дал понять в начале топика, что используемые фичи универсальны.
2. Не вижу ни чего плохого в использовании универсального подхода, а не MySQL направленного.

[2fast4rabbit]

А я их считаю очень даже уместными. Вы указали в заголовке статьи «MySQL performance», в тегах указали «mysql performance tricks». Так что я в праве считать что статья о MySQL, по этому я считаю что в данном случае уместно использовать дериктивы MySQL для решения данных задач, нежели использовать костыли.

[Casus]

Ваше право.
Я описал приёмы которые в первую очередь улучшают быстродействие запросов в MySQL, с оговоркой, что методы универсальны.
мои методы неприменимы в MySQL? основной упор топика не MySQL?

[2fast4rabbit]

Рискну предположить что конструкция «object+0=0» добавит одну избыточную операцию сложения для каждой строки на стадии «фильтрации» результатов. Таким образом мы получим для таблицы со 100к записей, 100к избыточных операций сложения. И для чего нам 100к избыточных операций если мы можем явно указать какой индекс использовать?

[zerkms]

dev.mysql.com/doc/refman/5.5/en/where-optimizations.html
Нет, не должно оно выполнять такую математику с каждой строкой

[equand]

Есть более сложные случаи, вот клиент вопрошал почему у него тормозит сайт на наших VPS. Затем начали разбирать сайт, оказалось 93 запроса, примерно вот таких:
SELECT count(*) FROM ru_tovar AS tovar WHERE spec='yes' AND tovar_id='0' AND nalichie>0
SELECT tovar.* FROM ru_tovar AS tovar WHERE 1=1 AND nalichie>0 AND spec='yes' AND tovar_id='0' AND nalichie>0 ORDER BY RAND() LIMIT 9
SELECT count(*) FROM ru_tovar AS tovar WHERE new='yes' AND tovar_id='0' AND nalichie>0
SELECT tovar.* FROM ru_tovar AS tovar WHERE 1=1 AND nalichie>0 AND new='yes' AND tovar_id='0' AND nalichie>0 ORDER BY RAND() LIMIT 3
SELECT count(*) FROM ru_tovar AS tovar WHERE hit='yes' AND tovar_id='0' AND nalichie>0
SELECT tovar.* FROM ru_tovar AS tovar WHERE 1=1 AND nalichie>0 AND hit='yes' AND tovar_id='0' AND nalichie>0 ORDER BY RAND() LIMIT 3
SELECT menu_id, proizvod_id, path_id FROM ru_tovar

Объяснение, что это можно объединить в один запрос ему не подходит, т.к. цмс написанная им «так не сработает»…
Более того, дальше есть выборка всей БД для подсчета товаров…

[muzzle]

Немного оффтоп.

Есть такие затейники.
Недавно попался очередной перл подобных ЦМСостроителей.
Простой отчетик по заказам на сайте, вначале месяца формируется еще терпимо, к концу месяца начинает тупить минут по 10 (если не обламывается по лимиту памяти). На выдаче у него от силы 3К строчек, типа №/Датавремя/Покупатель/Точка продажи/Сумма.
Полез доставать скелеты из шкафа.

Две основных таблицы TABLE_ORDERS и TABLE_ORDERS_PRODUCTS. Из индексов — только праймари. Причем ни одного поля из TABLE_ORDERS_PRODUCTS, в этом запросе не используется. Смотришь план — а там перебор 100К х 30К записей через filesort и temptable.

Собственно запрос, для ценителей.
$products_query_raw = "select distinct o.orders_id, o.point,o.orders_status, o.customers_name, o.customers_city, o.customers_street_address ,
o.customers_telephone, o.customers_id, o.payment_method, o.date_purchased, o.last_modified, o.currency, o.currency_value, s.orders_status_name
from " . TABLE_ORDERS_STATUS . " s, " . TABLE_ORDERS . " o
inner join " . TABLE_ORDERS_PRODUCTS . " op on (o.orders_id = op.orders_id)
where o.orders_status = s.orders_status_id
and o.point<> '".$pzstore."'
and UNIX_TIMESTAMP(o.date_purchased) > $startDate
and UNIX_TIMESTAMP(o.date_purchased) <= $endDate
and Hour(o.date_purchased)*60+Minute(o.date_purchased) > '".intval(date("H",$startDate)*60+date("i",$startDate))."'
and Hour(o.date_purchased)*60+Minute(o.date_purchased) <= '".intval(date("H",$endDate)*60+date("i",$endDate))."'
group by o.orders_id
order by o.date_purchased DESC";


Ну и само собой, запрос прогоняется два раза, посчитать строчки и получить данные.
А потом в цикле пробежка по результатам, на каждую строчку выдачи рожается объект «заказ», в который вычитываются данные (снова!) из базы, и пересчитывается сумма (сумма то заказа нигде не хранится). Складывается все в массив, который потом сортируется и выдается.

[muzzle]

Однако тэг code в предпросмотре и в публикации ведет себя по разному.
Ну вот откуда подгреблись эти лишние переводы строк?

[muzzle]

Ну, не переводы конечно, а стиль
white-space: pre-wrap;

[NaN]

О Боже! Да это же OSCommerce…
Страна должна знать своих героев)
Весь код этой цмс можно выложить куда-нибудь в качестве пособия «никогда так не делай».

[muzzle]

Да, это она.
Только дополненная и переработанная командой «профессионалов».
Там весь проект — яркий пример «никогда так не делай».

[AnGr]

и с этим вы тоже работали??? я так долго никогда не ругалась!!! за один день!!! :( соболезнования!

[NaN]

Скажем так, я с этим постоянно работаю(((

[AnGr]

Тогда мои самые искренние соболезнования… ибо я вас понимаю как никто! :(

[AnGr]

Мальчик не из Украины и не Шевчук ли фамилия??? Я такое тоже видела в коде %(

[AntonShevchuk]

Каким макаром меня вдруг к OSCommerce приписали О_о

[AnGr]

ой, не Вас, что Вы :))))

[AntonShevchuk]

Можно на ты, а то как-то неуютно… :)

[ComodoHacker]

Уберите пожалуйста в коде лишние переводы строк. Читать очень сложно, особенно планы.

[Casus]

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

[ComodoHacker]

Посмотрите ваш текст в hex, может вы чего лишнего из консоли скопировали.