Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
function get_afisha()
{
global $database;
$i=2;
while(count($row)<4)
{
$query='
(
SELECT DISTINCT ae.id, ae.title
FROM afisha.#__afisha_events ae
WHERE ae.published = 1 AND
ae.deleted = 0 AND
ae.type_event = 1 AND
ae.id IN (SELECT aed.id_event FROM afisha.#__afisha_event_dates aed WHERE aed.date >= CURDATE()) AND
ae.city=1
ORDER BY RAND()
LIMIT 1
)
union
(
SELECT c.id,c.title
FROM night.#__content c
LEFT JOIN night.#__content_afisha_date ca
ON c.id = ca.id_content
WHERE c.state=1 AND
c.access=0 AND
ca.date >= CURDATE() AND
c.catid=5 AND
ae.city=1
GROUP BY c.id, ca.id_content
ORDER BY RAND()
LIMIT 1
)
union
(
SELECT DISTINCT ae.id, ae.title
FROM afisha.#__afisha_events ae
WHERE ae.published = 1 AND
ae.deleted = 0 AND
ae.type_event = 4 AND
ae.id IN (SELECT aed.id_event FROM afisha.#__afisha_event_dates aed WHERE aed.date >= CURDATE()) AND
ae.city=1
ORDER BY RAND()
LIMIT 1
)
union
(
SELECT DISTINCT ae.id, ae.title
FROM afisha.#__afisha_events ae
WHERE ae.published = 1 AND
ae.deleted = 0 AND
ae.type_event = 2 AND
ae.id IN (SELECT aed.id_event FROM afisha.#__afisha_event_dates aed WHERE aed.date >= CURDATE()) AND
ae.city=1
ORDER BY RAND()
LIMIT 1
)';
$database->setQuery($query);
$row=$database->loadObjectlist();
$i++;
}
return $row;
}
$row=get_afisha();
> Это говно вешало наш 8 ядерный сервер с 16 гигами оперативы
а вы всмотритесь в строчки 16,31,43,55 и поймете почему
еще подзапросы в строчках 14,41,53 мне кажутся избыточными - думаю, если их вынести в отдельный запрос, можно уже будет обойтись 2ядерным сервом с 4гигами оперативы.
А если потрудитесь обьяснить задачу этого ужасного запроса, то наверное вполне можно будет сократить его обьем раз в 5, да и скорость увеличится.
1. беглый осмотр кода показывает оооочень размазанный скул-запрос, так что, при равной возможности каждой строчки на содержание говна, скул сразу попадает под подозрение
2. далее, опять же, не вникая в код, мы видим, что визуально он представляет собой несколько похожих кусков, следовательно, количество информации в них меньше (архиваторы неплохо бы сжали) - что только подкрепляет гипотезу 1
3. далее, обращая внимание только на бросающиеся ключевые слова, видим много селектов, а так же чудовищную строку ORDER BY RAND(), что более-менее опытным кодерам известна.
4. дальше концентрат говна детектед, далее лень разжевывать кодеру, что да как
Предположительно, например, первый и третий куски можно объединить, при условии "type_event in (1,4 )", как минимум.
Проблемы всегда начинаются, когда лезут в калашный ряд те, кто не разбираются в предмете. В результате, если ещё php как-то нагрузку держит, базы начинают затыкаться на ровном месте.
а что значит "разбираться в предмете"? автор сабжа вполне умеет писать скул-запросы. А оптимизация запросов это предметная область, или все же изыски опытных кодеров?
К примеру, в университете у нас, помнится, был предмет "системы управления базами данных", и там, среди прочих базовых знаний, учили даже нормальным формам вплоть до четвертой. Предмет пройден, то есть, считается, что нас обучили как следует. Однако про оптимизацию запросов пришлось интересоваться самому + здравый смысл + эмпирический опыт.
Значит, те, кто может/хочет - те научатся. Любимая фраза же всех остальных "профессионалы построили Титаник".
Не думаю, что интститут мне дал что-то кроме скупого базиса. Ну, по крайней мере, с join'ами пришлось разбираться самостоятельно.
Тем не менее, некоторые отрасли требовательнее к кодомартышкам, нежели другие. И запросы подобного рода, например, им с рук уже не сходят. Тут уже не скачать компонент, который "сделает все хорошо". И не скопипастить кусочек функции на форуме. Вот и получается, что регулярки у обезьян - совершенно ненормальные, запросы жрут сотни памяти через одного.
Уметь писать запрос и уметь написать корректный запрос - два совершенно разных умения.
тут дело в подходе.
есть два совершенно разных подхода, и их носители друг друга не понимают.
первый: "мне надо работать с FOO. Сейчас я разберусь, как с ней правильно работать, пойму ее идеологию, почитаю бестпрактисы, подпишусь на рассылку, и через недельку буду сносно рубить в FOO".
второй: "мне надо работать с FOO. Но времени (да и сил) разбираться с ним нет. В конце концов -- я же специалист по BAR , а не по FOO, мне не за это платят. Сейчас я скопирую готовый код с форума, и если он заработает -- все ок. Если что-то сглючит -- будем разбираться, в конце концов на форуме мне всегда помогут".
Я видел такое и среди админов и среди программеров.
есть ещё третий: "мне надо работать с FOO. Но времени (да и сил) разбираться с ним нет. В конце концов -- я же специалист по BAR. Сейчас я [немножко] пойму ее идеологию, и через недельку перепишу FOO на BAR."
---
PS копипаста - зло...
а вы всмотритесь в строчки 16,31,43,55 и поймете почему
еще подзапросы в строчках 14,41,53 мне кажутся избыточными - думаю, если их вынести в отдельный запрос, можно уже будет обойтись 2ядерным сервом с 4гигами оперативы.
А если потрудитесь обьяснить задачу этого ужасного запроса, то наверное вполне можно будет сократить его обьем раз в 5, да и скорость увеличится.
рефакторинг -> уберите $i
2. далее, опять же, не вникая в код, мы видим, что визуально он представляет собой несколько похожих кусков, следовательно, количество информации в них меньше (архиваторы неплохо бы сжали) - что только подкрепляет гипотезу 1
3. далее, обращая внимание только на бросающиеся ключевые слова, видим много селектов, а так же чудовищную строку ORDER BY RAND(), что более-менее опытным кодерам известна.
4. дальше концентрат говна детектед, далее лень разжевывать кодеру, что да как
Проблемы всегда начинаются, когда лезут в калашный ряд те, кто не разбираются в предмете. В результате, если ещё php как-то нагрузку держит, базы начинают затыкаться на ровном месте.
К примеру, в университете у нас, помнится, был предмет "системы управления базами данных", и там, среди прочих базовых знаний, учили даже нормальным формам вплоть до четвертой. Предмет пройден, то есть, считается, что нас обучили как следует. Однако про оптимизацию запросов пришлось интересоваться самому + здравый смысл + эмпирический опыт.
Не думаю, что интститут мне дал что-то кроме скупого базиса. Ну, по крайней мере, с join'ами пришлось разбираться самостоятельно.
Тем не менее, некоторые отрасли требовательнее к кодомартышкам, нежели другие. И запросы подобного рода, например, им с рук уже не сходят. Тут уже не скачать компонент, который "сделает все хорошо". И не скопипастить кусочек функции на форуме. Вот и получается, что регулярки у обезьян - совершенно ненормальные, запросы жрут сотни памяти через одного.
Уметь писать запрос и уметь написать корректный запрос - два совершенно разных умения.
есть два совершенно разных подхода, и их носители друг друга не понимают.
первый: "мне надо работать с FOO. Сейчас я разберусь, как с ней правильно работать, пойму ее идеологию, почитаю бестпрактисы, подпишусь на рассылку, и через недельку буду сносно рубить в FOO".
второй: "мне надо работать с FOO. Но времени (да и сил) разбираться с ним нет. В конце концов -- я же специалист по BAR , а не по FOO, мне не за это платят. Сейчас я скопирую готовый код с форума, и если он заработает -- все ок. Если что-то сглючит -- будем разбираться, в конце концов на форуме мне всегда помогут".
Я видел такое и среди админов и среди программеров.
---
PS копипаста - зло...
а потом:
--зачем ты пишешь десктопное приложение и демона на php?
--потому что я php уже знаю, а другие языки -- нет
копипастить точно умеет
Не уж-то все дело в инкременте $i... 🙂