所以我有这个超级查询,根据他们与原始文章(在$ id变量中提供)共有的标签数量找到“相关文章”。我不知道实际的查询是否重要,但这里是Justin Case。
现在,我从未在实际项目中实际使用过程,但我读过它们应该更快,部分原因是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 ;
答案 0 :(得分:1)
欢迎来到MySQL的真实世界! 有时很难说为什么一个查询执行的时间长于另一个查询。但在你的情况下,答案可以找到here:
MySQL不使用缓存来查询已从存储中调用 程序
答案 1 :(得分:0)
对你的延迟并不积极,但IN SUBSELECTS本身可能代价高昂。您是否考虑过加入现在的子选择?此外,由于articles表是查询的基础,而a.id = rel.article_id,如果通过索引可用,则“a.id”上的group by可能会更好。
SELECT
a.id,
a.image,
a.title,
a.excerpt,
a.permalink
FROM
articles AS a
JOIN category_relations AS rel
ON a.id = rel.article_id
JOIN categories AS c
ON rel.category_id = c.id
AND c.type = 1
JOIN (SELECT category_id
FROM admin_category_relations
WHERE article_id = {$id} ) RelByArticle
on rel.category_id = RelByArticle.category_id
WHERE
a.id != {$id}
GROUP BY
a.id
ORDER BY
n DESC,
publish_date DESC
LIMIT 10