そこで、元の記事 ($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 ;