SQL Server-大きなヒープにクラスター化インデックスを作成する-列を追加する必要がありますか？
かなり大きなテーブルにクラスター化インデックスを追加します。
- 700万件を超えるレコード
- 106列
- pKなし
- 他のインデックスはありません。
インデックスキーに使用される可能性のあるId列がありますが、それはnvarchar(18)および_not unique_です（ただし、重複する値はありません）。
ただし、そのデータ型（パフォーマンスへの影響）のため、使用することに消極的であり、int identity(1,1)列を追加して、クラスター化インデックスキーとして使用することを考えています。
どちらのソリューションをお勧めしますか？ TIA
INT identity（1,1）列を追加し、それをクラスター化インデックスキーとして使用することを検討している
はい、これは行く方法です
理由-以下をお読みください：
適切なクラスター化インデックスの要件：
1）増え続ける
これは、将来的にインデックスの断片化を減らすのに役立ちます
2）一意
クラスター化インデックスキーの行が一意でない場合、SQL Serverによって非表示のINT一意化記号（4バイト）が自動的に追加され、クラスター化インデックスキーが一意になり、クラスター化インデックスと非クラスター化インデックスの両方のストレージ要件が増加します。 （クラスター化インデックスキーの非表示のコピーが含まれているため、クラスター化インデックスの幅の影響も受けます）
）狭い
ストレージとRAM要件が増加し、パフォーマンスが低下するため、可能な限り小さいデータタイプを選択してください
これが、あなたが持っているId nvarchar(18)がクラスター化インデックスキーの候補として不適切な理由です。先に進んで、INT identity（1,1）列を追加してください。
一般に、サロゲートID（他の意味を持たない増分番号）は、機能しない特定の理由がない限り、最良の選択です。
主キーにインクリメントしない値を使用する場合の最大の問題の1つは、一部の挿入でページ分割が発生し、挿入が遅くなることです。どのくらい遅くなるかは多くの要因に依存するため、システムで測定する必要があるものにすぎません。
グーグルの「代理主キーの利点」とあなたはたくさんの情報を見つけるでしょう。これは実際にトピックをカバーする小さな本なので、完全な答えはこのサイトにはあまり適切ではありません。 この質問 にも、このトピックに関する適切な情報を提供するいくつかの回答があります。