0
私は毎晩実行されるプロセスをサポートしており、未払いの広告申込情報のある請求書を持つさまざまなクライアントを見ています。このプロセスは、ステージングテーブルからすべてのレコードを削除してから、いくつかの請求書明細をステージングテーブルに挿入することから始まります。プロセスはクライアントごとに実行されるため、一部のクライアントでは200個の広告申込情報があり、一部のクライアントでは50,000個の広告申込情報がある場合があります。私たちは絶えず膨大な時間を費やしているプロセスに常に問題を抱えています。この問題は、SQL Serverがその時点でステージングテーブルにある正しい行数を見積もることができないために、不正な実行計画が生成されているように見えます。私の質問は、関与するストアドプロシージャのカーディナリティ推定を向上させるために、行数を手動で設定する方法はありますか？これは、実行の開始時に選択カウント（primaryKey）を使用して実行することができます。現在の実行ステージング・テーブルにデータが移入された直後ですか？ステージングテーブルのカーディナリティ推定を改善するにはどうすればよいですか？
削除して挿入し、ステージングテーブルから選択しない場合は、なぜSQLはステージングテーブルの統計データを使用しますか？たぶん私は何かが欠けているでしょう。ステージングテーブルのデータに基づいて挿入/削除を選択またはマージしてベースにしていない限り、統計はなぜ重要なのでしょうか？それとも、削除/挿入が完了した後に話しているのですか？ステージングテーブルの解析が遅いですか？あなたはテーブル/インデックスビューで強制更新を試しましたか？ https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-updatestats-transact-sql – xQbert
プロセスが開始する前に、テーブルの統計を更新することができます。 https://docs.microsoft.com/en-us/sql/t-sql/statements/update-statistics-transact-sql。統計を更新した後、ストアド・プロシージャを再コンパイルして、SQLに新しい実行計画が提示されるようにすることができます。 https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-recompile-transact-sql – Jason
すべての行を削除して再投入すると、統計は更新されます。おそらく、異なるクライアントの行数が大きく異なるが、遭遇した最初のものに対して計画がコンパイルされただけで、パラメータスニッフィングが発生している可能性があります。この場合、問題のクエリに 'OPTION（RECOMPILE）'を追加すると便利です。 –