現時点では、主キーでnewid（）を使用しているいくつかのテーブルがあります。これは大量の断片化を引き起こしています。だから、代わりにnewsequentialid（）を使用するように列を変更したいと思います。既存のテーブルでnewid（）をnewsequentialid（）に変更する
私は、既存のデータはかなり断片化したままであると思いますが、新しいデータの断片化は少ないと思います。これは、PKインデックスをクラスタ化されていないものからクラスタ化されたものに変更する前に、しばらく待つ必要があることを意味します。
私の質問は、誰もこれをやる経験がありますか？私が慎重にすべきことを見落としたことはありますか？
逐次ガイドとに同時にインデックスを再編成すると、断片化がなくなります。断片化されたページのリンクが連続して再配置されるまで待つ必要がある理由はわかりません。
これは、フラグメンテーションが実際にシステムに影響を与えていることを示すために測定しましたか？インデックスを見て、 '断片化されているのは75％です'と表示されますではなく、はアクセス時間に影響します。バッファプールのページ寿命、書き込み速度と書き込み速度、順次操作の局所性、操作の並行性などがあります。 guidから順次guidへの切り替えは安全ですが、まだ問題が発生する可能性があります。たとえば、インサートが集中するホットスポットページを作成するため、インサート集中型OLTPシステムのページラッチ競合を確認できます。
これがSQL Serverの場合、newid（）を呼び出してGuidを生成しています。これはプライマリキーには適していません。プライマリキーに整数のID列を使用し、Guidをサロゲートキー（および行GUID列）にします。
そのため、代わりにnewsequentialid（）に切り替えようとしています。 –
newsequentialidではなくcomb guidsを使用すると思います。櫛GUIDのシーケンシャルな世代が昇順で互いに近く、一般的にあるよう
cast(
cast(NewID() as binary(10)) +
cast(GetDate() as binary(6))
as uniqueidentifier)
櫛形GUIDは、現在の日時の非ランダムと共に純粋にランダムなGUIDの組み合わせです。あなたがブラックボックスではないという事実、既定の制約の外でこの数式を使用できること、そしてSQL Serverの外部でこの数式を使用できるということを含む、新しい列のIDよりも複数の利点があります。
私はそれらについて考えましたが、私は「サポートされている」機能を使いたいと思っています。理論的にはnewid（）からCOMBへテーブルを切り替えることはできますが、データ型は同じですが問題はありません。 – cbp
ありがとう、yfeldblum！ COMB GUIDの簡潔で簡潔な説明が本当に私を助けました。私は実際にこの記事の逆を見ていました。SQL Server 2012 dbをAzureに移行しようとしていたのでnewsequentialid()に頼る必要がなくなり、newsequentialid()機能はそこでサポートされていません。
私は、次の構文で、COMB用のGUIDに私のテーブルのPKのデフォルトのすべてを変更することができました：
ALTER TABLE [dbo].[Company]
ADD CONSTRAINT [DF__Company__Company_ID__72E6D332]
DEFAULT (CONVERT([uniqueidentifier],CONVERT([binary](10),newid(),0)+CONVERT([binary](6),getdate(),0),0)) FOR [CompanyId]
GO
私のSQL2012 DBは今幸せにAzureのクラウドに住んでいます。
ありがとうRemus - 面白いコメント。私は前に一度 'ページラッチの競合'について聞いたことがありますが、GUIDの引数とGUIDの引数ではめったに言及されていないようです。 あなたは正しいと思いますが、クラスタ化されたインデックスに切り替える前に私が考えていたのはおそらく間違っていました。 – cbp
システムには十分なプロセッサとページラッチの競合が発生するのに十分な秒数が必要です。そのアイロニックは、1つのホットスポットを複数のウォームスポットに分割する（つまり、1つの値ではなく複数の値を挿入する）ことで、最終的にフラグメンテーションを引き起こします。 –