10

多数の行 (10K+) を持つテーブルがあり、主キーは GUID です。主キーはクラスター化されています。このテーブルでは、クエリのパフォーマンスが非常に低くなります。効率化するための提案をお願いします。

4

6 に答える 6

42

GUID のクラスター化インデックスは適切な設計ではありません。GUID の本質はランダムであることですが、クラスター化されたインデックスはキーによってレコードを物理的に並べ替えます。2つのことは完全に対立しています。挿入するたびに、SQL はディスク上のレコードを並べ替える必要があります。このインデックスからクラスタリングを削除してください!

クラスタリングを使用するタイミングは、データに「自然な」順序 (挿入された時間、アカウント番号など) がある場合です。時間フィールドの場合、クラスタリングはほとんど無料です。口座番号については、無料の場合と安い場合があります（口座番号が連続して割り当てられている場合）。

GUID の問題を回避する技術的な方法があるかもしれませんが、最適な方法は、クラスタリングをいつ使用するかを理解することです。

于 2009-02-24T18:46:58.490 に答える
7

GUID を主キーとして使用しても問題はありません。実際に GUID を主キーに設定するときは、自動的に作成されるインデックスを非クラスター化タイプに設定してください。多くの人は、SQL Server でこれを行うことを忘れています (または知らない)。

GUID でクラスター化インデックスを使用しないでください。これにより、ディスク上のGUIDの周りに物理的な順序が発生しますが、これは明らかに無意味です（他の人がすでに指摘しているように）

于 2010-04-22T11:08:10.363 に答える
5

代わりに、 newsequentialid () を使用する必要があります。こちらを参照してください。

于 2009-02-24T18:48:15.663 に答える
2

インデックスをより効果的にする順次 GUIDS を試すことができます。情報はこちら。

于 2009-02-24T18:43:34.877 に答える
1

クエリを分析する必要があります。実行計画を表示せずにクエリのパフォーマンスが悪い理由を推測することしかできません (SQL Server または Oracle から簡単に静かにすることができます)。

GUID が 128 ビット値であることを考慮すると (未加工で保存されている場合)、GUID はデータ ブロックとインデックス ブロックの密度を 50% 削減する (主キー インデックスの場合) ため、GUID が適切であることを確認してください。

しかし、それは問題ではない可能性があるため、クエリ プランを確認してください。他にもいくつかの問題がある可能性があります。

于 2010-03-10T16:01:31.347 に答える
-5

長い文字列列に対してクラスター化インデックスを作成しないようにしてください。GUID は 36 文字になります。クラスター化インデックスとして作成した場合でも、クエリのパフォーマンスが低下します。より良い実践のために、整数 ID 列を使用してください。

于 2009-12-02T10:35:46.803 に答える