5

私たちは SQL タイムアウトを経験しており、そのボトルネックが監査テーブルであることを特定しました。システム内のすべてのテーブルには、新しい監査レコードの原因となる挿入、更新、および削除のトリガーが含まれています。

これは、監査テーブルがシステム内で最大かつ最もビジーなテーブルであることを意味します。ただし、データは入ってくるだけで出てこない (このシステムでは) ため、selectパフォーマンスは必要ありません。

返品を実行するselect top 10と、「最初の」レコードではなく最近レコードが挿入されます。 order byもちろん動作しますが、select top はディスク上の順序に基づいて行を返す必要があると思います.これは最低の PK 値を返すと思います.

クラスター化されたインデックスを削除することが提案されており、実際には主キー (一意の制約) も削除されています。前に述べたようにselect、このシステム内のこのテーブルからする必要はありません。

クラスター化インデックスがテーブルに作成するパフォーマンス ヒットはどのようなものですか? 索引付けされていない、クラスター化されていない、キーのないテーブルを持つことの (非選択) 影響は何ですか? 他の提案はありますか？

編集

私たちの監査にはCLR関数が含まれており、現在、PK、インデックス、FKなどを使用して、または使用せずにベンチマークを行って、CLR関数と制約の相対的なコストを決定しています。

調査の結果、パフォーマンスの低下はinsertステートメントに関連するものではなく、監査を調整する CLR 機能に関連するものでした。CLR を削除し、代わりに単純な TSQL プロシージャを使用すると、パフォーマンスが 20 倍向上しました。

テスト中に、クラスター化されたインデックスと ID 列は、少なくとも他の処理と比較して、挿入時間にほとんど、またはまったく違いがないことも確認しました。

// updating 10k rows in a table with trigger

// using CLR function
PK (identity, clustered)- ~78000ms
No PK, no index - ~81000ms

// using straight TSQL
PK (identity, clustered) - 2174ms
No PK, no index - 2102ms
4

4 に答える 4

9

Kimberly Tripp（インデックス作成の女王）によると、テーブルにクラスター化インデックスを設定すると、実際にINSERTのパフォーマンスが向上します。

クラスター化されたインデックスの議論は続く

  • 挿入は、ヒープと比較して、クラスター化されたテーブル（ただし「正しい」クラスター化されたテーブルのみ）で高速です。ここでの主な問題は、ヒープ内の挿入場所を決定するためのIAM / PFSでのルックアップが、クラスター化されたテーブル（挿入場所がわかっている場合、クラスター化されたキーによって定義される）よりも遅いことです。順序が定義されているテーブル（CL）に挿入すると、挿入が高速になり、その順序が増え続けます。

出典：クラスター化されたインデックスの議論が続くというブログ投稿...

于 2011-09-01T04:52:49.747 に答える
4

このシナリオの優れたテストスクリプトと説明は、 SQLblog.comのTiborKarasziのブログで入手できます。

私の数値は彼の数値と完全には一致していません。バッチステートメントでは、行ごとのステートメントよりも多くの違いが見られます。

行数が約100万であるため、クラスター化インデックスで単一行の挿入ループをかなり一貫して取得し、インデックスなしよりもわずかに高速に実行します（クラスター化にはインデックスなしの約97％の時間がかかります）。

逆に、バッチ挿入（10000行）は、クラスター化インデックスよりも非インデックス化インデックス（クラスター化挿入時間の75％〜85％）の方が高速です。

clustered - loop        - 1689
heap      - loop        - 1713
clustered - one statement - 85
heap      - one statement - 62

彼は、各挿入で何が起こっているかを説明します。

ヒープ： SQL Serverは、行を配置する場所を見つける必要があります。このために、ヒープに1つ以上のIAMページを使用し、データベースファイル用にこれらを1つ以上のPFSページに相互参照します。IMO、ここで顕著なオーバーヘッドが発生する可能性があります。さらに、多くのユーザーが同じテーブルをハンマーで叩いているので、PFSおよび場合によってはIAMページに対してブロック（待機）することを想像できます。

クラスター化されたテーブル：これは非常に単純です。SQL Serverは、クラスター化されたインデックスツリーをナビゲートし、行を配置する場所を見つけます。これは増え続けるインデックスキーであるため、各行はテーブルの最後に移動します（リンクリスト）。

于 2011-09-01T06:29:40.820 に答える
2

鍵のないテーブル？自動インクリメントの代理キーすらありませんか? :(

キーが単調に増加している限り、挿入時のインデックスのメンテナンスは適切です。「最後に追加される」だけです。「クラスター化」とは、テーブルの物理レイアウトがインデックスに従うことを意味します (データはインデックスの一部であるため)。インデックスが断片化されていない限り (単調に増加するビットを参照)、クラスター自体/データは論理的に断片化されず、これはパフォーマンスの問題にはなりません。(更新がある場合、クラスタリングは少し異なる話です。更新されたレコードは「成長」し、断片化を引き起こす可能性があります。)

私の提案は、それが選択されたルートである場合...現実的なデータ/負荷でベンチマークし、そのような提案が保証されるかどうかを判断することです。この変更が決定された理由とその理由を確認できれば幸いです。

ハッピーコーディング。

また、注文以外の注文への依存ORDER BYは、設計上欠陥があります。現在は動作する可能性がありますが、これは実装の詳細であり、微妙な方法で変更される可能性があります (別のクエリ プランと同じくらい簡単です)。自動インクリメント キーを使用するORDER BY DESCと、常に正しい結果が生成されます (自動インクリメント ID はスキップできますが、「リセット」しない限り、挿入順序に基づいて常に増加することに注意してください)。

于 2011-09-01T00:03:32.167 に答える
2

私の基本的な理解は、通常、INSERT 操作でさえ、ヒープよりもクラスター化されたインデックスの方が高速であるということです。さらに、クラスター化インデックスを使用すると、必要なディスク容量が少なくなります。

特定の状況に光を当てる可能性のあるいくつかの興味深いテスト/シナリオ: http://technet.microsoft.com/en-us/library/cc917672.aspx .

于 2011-09-01T01:31:39.110 に答える