特定のテーブルへの挿入が遅い理由を知るにはどうすればよいですか？

SQLテーブルでのINSERTには、さまざまな理由で時間がかかることがあります。

• テーブル上のINSERT TRIGGERの存在
• チェックする必要のある強制された制約の多く（通常は外部キー）
• テーブルの中央に行が挿入されると、クラスター化インデックスでページが分割される
• 関連するすべての非クラスター化インデックスを更新する
• テーブル上の他のアクティビティからのブロック
• 不十分なIO書き込み応答時間
• ...私が見逃したものは何ですか？

特定のケースでどちらが責任があるのか​​をどのように確認できますか？ページ分割と非クラスター化インデックスの更新と他のすべての影響を測定するにはどうすればよいですか？

（一時テーブルから）一度に約10,000行を挿入するストアドプロシージャがあり、1万行につき約90秒かかります。他のspidがタイムアウトするので、これは受け入れられないほど遅いです。

実行計画を確認しました。INSERTCLUSTERED INDEXタスクとFKルックアップからのすべてのINDEX SEEKSを確認しましたが、なぜ時間がかかるのか確かではありません。トリガーはありませんが、テーブルには少数のFKey（適切にインデックス付けされているように見える）があります。

これはSQL 2000データベースです。

あなたが見ることができるいくつかのもの...

バッチサイズを10000から2000や1000などの小さいサイズに減らします（行サイズがどれほど大きいかは言いませんでした）。

IO統計を有効にして、FKルックアップがどれだけのIOを使用しているかを確認してください。

挿入が発生したときに発生する待機は何ですか（master.dbo.sysprocesses）？

ここから始めて、どこに行くか見てみましょう。

ブラッド、

クエリの待機統計を調べる必要があります。SQL2000では、DBCC SQLPERF（ "waitstats"）構文を使用してこれらの詳細を取得できます。

クエリのパフォーマンスを分析するときに、私が探しているものを言うことができます。たぶんそれが役立ちます。

• クエリ実行プランを分析し、インデックススキャン、テーブルスキャン、sqlデータ型のconvert_implicit関数の使用、並列性を確認します。
• SET STATISTICS IO ONおよびSET STATISTICS TIME ONでクエリを実行して、各挿入の実行時間と読み取り/書き込みioを確認します。
• セッションspidのsysprocessesから待機時間を確認してください。
• プロファイラーを実行し、標準テンプレートを選択します。以下を選択します：パフォーマンス統計（繰り返した場合、計画は何度もコンパイルされます-良くありません）、RPC：completed、SQL：batchcompleted、およびSQL：batchstarting。それらに列rowcountsを追加して、バッチの行数を正確に確認します。結果をフィルタリングして、クエリのみを表示します。
• 最後に 、Windows PerfmonからPage Life Expectancyカウンターを収集します。300（5分）未満の場合、SQLのメモリは少なくなります。また、ディスクカウンターを収集します。ディスクキューの長さ、ディスク時間（データファイルドライブ）、ディスク時間（ログファイルドライブ）は、ディスクに負荷がかかっているかどうかを確認します。

使用してみてください：

SET STATISTICS IO ON

そして

SET STATISTICS PROFILE ON

統計IO

どのテーブルが最も多くのテーブルスキャン、論理読み取り、物理読み取りを行っているかを知るのに役立ちます（これらの3つを使用して、クエリプランのどの部分が最もチューニングが必要かに焦点を当てます）

統計プロファイル

主にクエリプランを表形式で返します。次に、クエリで最もコストがかかるものについてIO列とCPU列を確認できます（一時テーブルのテーブルスキャンと、挿入するソートのどちらですか）クラスター化されたキーなど...）