Итак, у меня есть этот супер-дупер-запрос, который находит «связанные статьи» на основе количества тегов, которые они имеют вместе с исходной статьей (предоставляется в переменной $id). Я не знаю, важен ли сам запрос, но это Джастин Кейс.
На самом деле я никогда не использовал процедуры в реальном проекте, но я читал, что они должны быть быстрее, отчасти потому, что движку MySQL не нужно каждый раз интерпретировать код. Но когда я поместил этот же код в процедуру и вызвал эту процедуру, выполнение в среднем заняло примерно в 450 раз больше времени.
Почему? Это потому, что он возвращает несколько строк? Процедуры воняют при этом? Это потому, что я должен использовать входную переменную в своей процедуре? 450 это куча!
SELECT a.id, a.image, a.title, a.excerpt, a.permalink, COUNT(rel.category_id) AS n
FROM articles AS a
JOIN category_relations AS rel ON rel.article_id = a.id
JOIN categories AS c ON rel.category_id = c.id
WHERE rel.category_id IN (SELECT category_id
FROM category_relations
WHERE article_id = {$id})
AND a.id != {$id}
AND c.type = 1
GROUP BY rel.article_id
ORDER BY n DESC, publish_date DESC
LIMIT 10
Код, используемый для создания процедуры:
DROP PROCEDURE IF EXISTS get_related_articles;
DELIMITER //
CREATE PROCEDURE get_related_articles(IN id INT)
BEGIN
SELECT a.id, a.image, a.title, a.excerpt, a.permalink, COUNT(rel.category_id) AS n
FROM articles AS a
JOIN category_relations AS rel ON rel.article_id = a.id
JOIN categories AS c ON rel.category_id = c.id
WHERE rel.category_id IN ( SELECT category_id FROM category_relations WHERE article_id = id)
AND a.id != id
AND c.type = 1
GROUP BY rel.article_id
ORDER BY n DESC, publish_date DESC
LIMIT 10;
END //
DELIMITER ;
$id
вписывается в ваш запрос? Вы действительно сравнивали свой запрос? - person Kermit   schedule 07.03.2013n
вORDER BY n DESC
? - person Kermit   schedule 07.03.2013