大規模なファクトテーブルで英数字の外部キーにどのようにインデックスを付けますか？
英数字フィールドであるフィールドがあります。理想的には、一意でない識別子の暗号化フィールドです。多対多の関係で他のかなり大きなファクトテーブルを関連付けるために使用されます。このFKには他の属性がないため、このフィールドに関連するディメンションはありません。
例：Abcdefgh12345
このフィールドはかなり大きく成長しているデータウェアハウスにあり、ファクトテーブルは時間どおりにクラスター化され、このようなキーではクラスター化されていません。
列はVARCHAR(50)であり、45〜50の間でのみ変化します。チェックする必要がありますが、照合はSQL_Latin1_General_CP1_CI_AS。最適化のため、FKは使用していません。すべてETLによって制御されます。
断片化
キーのタイプが原因で、索引付けが困難になります。その断片化は、最近行った一連のテストによって管理されています。フルリビルドが必要になるまで少なくとも1週間、毎日の増分負荷の断片化を減らすことで75％のフィルファクターを少なくとも管理できることが示されました。
パフォーマンス
FILL FACTORが100％から75％に減少すると、挿入と読み取りが遅くなります。記録も予想通り大きくなりました。インクルードを含むインデックスは、挿入時のパフォーマンスを大幅に向上させますが、それらを必要とするクエリを10倍改善します。
質問
データウェアハウジング環境で英数字を使用した経験はありますか？それがどのように処理され、インデックスが作成されるかは問題ありませんが、もっと良い方法だと思います。私は、ETLプロセス中にキーを取り除き、新しい次元を形成し、より管理しやすいキーを追加するというアイデアを少しずつ考えていました。
_SQL_Latin1_General_CP1_CI_AS_の照合を使用したVARCHAR(50)フィールドに関する仮定が正しいと仮定すると、存在する各テーブルの英数字の「コード」フィールドを変更して、照合を行うことを検討する必要があります。 _Latin1_General_BIN2_の。値はアルゴリズムから導出されるため、大文字と小文字の区別は一貫している必要があります。大文字と小文字を区別しない検索について心配する必要はありません。バイナリ照合を使用すると、文化に対応した言語ルールを処理する必要がないため、非バイナリ照合（大文字と小文字を区別しない、または大文字と小文字を区別する）よりもパフォーマンスが向上します。
また、100と75の両方のFILLFACTOR設定を試し、それぞれの場合の長所と短所を確認したので、90の設定を試して、それが役立つかどうかを確認する必要があります。
これらの変更を個別に試して（最初の変更を加えてから、もう1つを追加して）、それらの効果を個別にテストできるようにします。そうすることで、各変更がどのように影響したかがわかります。
一般に、システムは45〜50バイトのキーを4バイトのキーに置き換えることでメリットがあると思います（これは次元データなのでINTを使用すると仮定しますが、8バイトのBIGINTでも可能です改善）。ただし、新しいディメンションテーブルを追加し、VARCHAR(50)をINT（またはBIGINT）に切り替えるには、データモデルとコードの両方に変更を加える必要があります。 2つの変更はデータモデルにのみ影響し、その場合は最小限です。