7

約 150 万の入力値で発生する興味深いパフォーマンスの変化に気付きました。なぜこれが起こっているのか、誰かが私に良い説明を与えることができますか?

表はとてもシンプルです。(bigint、bigint、bigint、bool、varbinary(max)) で構成されています。最初の 3 つの bigint に pk clusered インデックスがあります。データ varbinary(max) としてブール値「true」のみを挿入します。

その時点から、パフォーマンスはかなり一定しているように見えます。

凡例: Y (ミリ秒単位の時間) | X (10K を挿入)

ここに画像の説明を入力

また、グラフに一定の比較的小さな (時には非常に大きな) スパイクがあることにも興味があります。

スパイク前の実際の実行計画。

スパイク前の実際の実行計画

凡例:
挿入先のテーブル: TSMDataTable
1. BigInt DataNodeID - fk
2. BigInt TS - メイン
タイムスタンプ 3. BigInt CTS - 変更タイムスタンプ
4. ビット: ICT - 最後に挿入された値の記録を保持 (読み取りパフォーマンスが向上)
5. データ:データ
ブール値 現在のタイムスタンプを保持

環境
ローカルです。
リソースを共有していません。
これは固定サイズのデータ​​ベースです (拡張しないように十分です)。
(コンピューター、4 コア、8GB、7200rps、Win 7)。
(SQL Server 2008 R2 DC、プロセッサ アフィニティ (コア 1、2)、3GB、)

4

1 に答える 1

1

時間切れになったら実行計画を確認しましたか？統計によりプランが変更になる場合がございます。データは急速に増大するため、統計が変更され、異なる実行プランがトリガーされる可能性があります。

ネストされたループは少量のデータに適していますが、ご覧のとおり、時間はボリュームとともに増加します。次に、SQLクエリオプティマイザは、大量のデータに対して一貫性のあるハッシュまたはマージプランに切り替える可能性があります。

この理論をすばやく確認するには、統計の自動更新を無効にして、テストを再実行してください。その場合、「バンプ」は表示されないはずです。

編集：Falconは統計によってパフォーマンスが変化したことを確認したので、次のステップを実行できます。

私はあなたが一つずつ挿入をしていると思います、正しいですか？その場合（バルクを挿入できない場合）、ヒープ作業テーブルに挿入したほうがはるかに良いでしょう。その後、定期的に、行をバルクでターゲットテーブルに移動します。これは、挿入された行ごとに、SQLがキーの重複、外部キー、およびその他のチェックをチェックし、ページを常にソートおよび分割する必要があるためです。これらのチェックを少し延期する余裕があれば、素晴らしいインサートパフォーマンスが得られると思います。

この方法をメトリックロギングに使用しました。ロギングは、インデックス、外部キー、チェックのないプレーンヒープテーブルに入ります。10分ごとに、この種の新しいテーブルを作成し、トランザクション内に2つの「sp_rename」を使用して（迅速なスワップ）、テーブル全体を処理できるようにし、新しいテーブルがログを取得します。そうすれば、すべてのチェック、並べ替え、分割を1回だけまとめて行うことができます。

これとは別に、私はあなたの状況を改善する方法がわかりません。一般的に良好なパフォーマンスの鍵となるため、統計を定期的に更新する必要があります。

単一の列IDクラスター化キーとそれらの3つの列に追加の一意のインデックスを使用しようとするかもしれませんが、それが大いに役立つかどうかは疑問です。

挿入されたデータがシーケンシャルでない場合は、インデックスをパディングしてみてください。これにより、過度のページ分割、シャッフル、断片化が排除されます。定期的にパディングを維持する必要があり、オフタイムが必要になる場合があります。

それにHWアップグレードを与えようとするかもしれません。どのコンポーネントがボトルネックであるかを把握する必要があります。それはCPUかディスクかもしれません-この場合私のお気に入りです。あなたが一つずつ挿入物を持っているならば、記憶はおそらく私見ではありません。それなら簡単なはずです。CPU（グラフの上にぶら下がっている線）でない場合は、IOがあなたを妨げている可能性があります。より良いコントローラー、より良いキャッシュ、より高速なディスクを試してみてください...

于 2011-10-03T07:49:50.563 に答える