パラメーター スニッフィングは SQL ストアド プロシージャのパフォーマンスにどのような影響を及ぼしますか?また、それを最適化するにはどうすればよいですか?

SQL ストアド プロシージャの実行計画の最適化: パラメータ スニッフィングとその影響

SQL ストアド プロシージャのパフォーマンスは、既知の現象によって大きな影響を受ける可能性があります。パラメータスニッフィングとして。これは、データベース エンジンが、コンパイル時に指定された入力パラメータの値に基づいてストアド プロシージャの実行プランをコンパイルするときに発生します。

次のストアド プロシージャについて考えてみましょう。

CREATE PROCEDURE MyProc
    @MyDate DATETIME = NULL
AS
    IF @MyDate IS NULL SET @MyDate = CURRENT_TIMESTAMP
    -- Do Something using @MyDate

この例では、このシナリオでは、最初のコンパイル中に @MyDate が NULL として渡された場合、データベースはこの値に合わせて実行計画を最適化します。ただし、その後、他の入力値を使用してプロシージャを呼び出すと、それらの値が NULL であっても、パフォーマンスが低下する可能性があります。

パラメータ スニッフィングの影響

パラメータ スニッフィングでは、次のような問題が発生する可能性があります。いくつかの悪影響があります:

• 予測できない実行時間: ストアド プロシージャのパフォーマンスは、渡される入力値によって大幅に変化し、予測不能な実行時間につながる可能性があります。
• 不適切な実行計画: エンジンが非効率的な実行を生成する可能性があります。処理される実際のデータに最適ではない計画があり、クエリが遅くなる

ケーススタディ: パラメータ スニッフィングが間違っている

上記のケースでは、使用された値がNULL。この動作は異常であり、パラメータ スニッフィングに問題があることを示唆しています。

解決策: パラメータ スニッフィングを無効にする

解決策の 1 つは、次のようにパラメータ変数を使用してパラメータ スニッフィングを無効にすることです。

CREATE PROCEDURE MyProc
    @MyDate DATETIME = NULL
AS
    DECLARE @MyDate_Copy DATETIME
    SET @MyDate_Copy = @MyDate
    IF @MyDate_Copy IS NULL SET @MyDate_Copy = CURRENT_TIMESTAMP
    -- Do Something using @MyDate_Copy

への洞察問題

SQL Server 2005 の根本的な問題は、特定のパッチ レベルでのパラメーター スニッフィングに関する既知の問題です。 SQL Server 2008 では、OPTIMIZE FOR UNKNOWN 句を使用してこのような問題を解決できます。

追加の考慮事項

入力パラメーターを含むストアド プロシージャを使用する場合のパフォーマンスをさらに向上させるには、次のようにします。次のことをお勧めします:

• パラメータ化されたクエリを使用して、データベースを確実に保護します。実行計画を効率的に最適化します。
• 意図しない最適化の問題を引き起こす可能性があるため、入力パラメータとして NULL 値を使用しないでください。
• ストアド プロシージャのパフォーマンスを定期的に監視し、必要に応じて実行計画を調整します。

以上がパラメーター スニッフィングは SQL ストアド プロシージャのパフォーマンスにどのような影響を及ぼしますか?また、それを最適化するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。