5

現在、主キーに newid() を使用しているテーブルがいくつかあります。これにより、大量の断片化が発生しています。そのため、代わりに newsequentialid() を使用するように列を変更したいと思います。

既存のデータはかなり断片化されたままになると思いますが、新しいデータは断片化が少なくなります。これは、PK インデックスを非クラスター化からクラスター化に変更する前に、しばらく待つ必要があることを意味します。

私の質問は、これを行った経験がある人はいますか? 気をつけなければならないことを見落としていることはありますか？

4

4 に答える 4

4

newsequentialid とは対照的に、 comb guidsの使用を考えるかもしれません。

cast(
    cast(NewID() as binary(10)) +
    cast(GetDate() as binary(6))
as uniqueidentifier)

Comb guid は純粋にランダムな guid と現在の日時の非ランダム性を組み合わせたものであるため、comb guid の連続する世代は互いに近く、一般に昇順になっています。Comb GUID には、新しいシーケンシャル ID よりもさまざまな利点があります。これには、ブラック ボックスではないこと、既定の制約の外部でこの式を使用できること、および SQL Server の外部でこの式を使用できることが含まれます。

于 2009-05-27T01:40:02.487 に答える
3

シーケンシャルガイドに切り替えて、同時にインデックスを再編成すると、断片化が解消されます。断片化されたページ リンクが連続した範囲で再配置されるまで待ちたい理由がわかりません。

そうは言っても、断片化が実際にシステムに影響を与えていることを示すために何らかの測定を行いましたか? インデックスを見て「75% 断片化されている」と表示されても、アクセス時間に影響があるとは限りません。関係する要素は他にもたくさんあります (バッファー プール ページの平均寿命、読み取りと書き込みの比率、順次操作の局所性、操作の同時実行性など)。GUID からシーケンシャル GUID への切り替えは通常安全ですが、それでも問題が発生する可能性があります。たとえば、挿入が集中する OLTP システムではページ ラッチの競合が見られます。これは、挿入が蓄積されるホットスポット ページが作成されるためです。

于 2009-05-27T01:45:41.773 に答える
-4

これが SQL Server の場合、newid() を呼び出して Guid を生成しています。これは主キーには適していません。主キーに整数 ID 列を使用し、Guid を代理キー (および行の GUID 列) にします。

于 2009-05-27T01:27:36.753 に答える