0

最近、SQL 開発で働いている私の同僚の 1 人が次のような問題に遭遇しました。手順はすべての環境で正常に実行されましたが、最もリソースが多い本番環境で実行されました。パラメーター スニッフィングの典型的なケースですが、プロファイラーは、手順全体で 1 つのクエリだけが実行に非常に時間がかかることを示しました。

UPDATE  a
SET     status_id = 6
FROM    usr.tpt_udef_article_grouping_buffer a
        LEFT JOIN (SELECT DISTINCT buying_domain_id, suppl_no FROM usr.buyingdomain_supplier_article) b ON  a.buying_domain_id = b.buying_domain_id
                                                                                                        AND a.suppl_no = b.suppl_no
WHERE   a.tpt_file_id = @tpt_file_id
        AND a.status_id IS NULL
        AND b.suppl_no IS NULL

私は開発に偏っているので (管理経験はほとんどありません)、このクエリを書き直すことを提案しました。

  • LEFT JOIN (SELECT DISTINCT ...)と置き換えますNOT EXISTS (SELECT 1 ...)

  • テーブルに適切なインデックスを配置しますusr.tpt_udef_article_grouping_buffer(クエリがプロシージャの外で実行された場合、SSMS は労力を 95% 削減することを提案しました)。

また、プロシージャーからの複数の照会が同じパターンを共有していました。

パラメーターのスニッフィングは、(再) 作成後に初めてプロシージャーを実行するときのプランの構築により関連していることを知っています。

私の質問は:

プロシージャ内のクエリの記述方法 (最初から不適切な実行計画) は、パラメータ スニッフィングの外観に有利に働くのでしょうか、それともその効果を悪化させるだけでしょうか?

4

1 に答える 1