2

問題は、列を追加するか、データベース テーブルを分割することです。

以下を保持するテーブルがあるとします。

UserId - Primary Key
Col1
Col2
Col3

ここで、別のデータを Col4 Col5 として保持しますが、このデータはすべての UserId に対して有効ではありません。

メイン テーブルに 200 万のレコードがあり、この追加データは 25000 レコードに対してのみ有効であるとします。問題は次のとおりです。次のように別のテーブルを作成する必要があります

UserId - Primary Key
Col4
Col5

また

私のメインテーブルを

UserId - Primary Key
Col1
Col2
Col3
Col4
Col5

どちらに行けばいいですか？パフォーマンスが気になります。これらの追加の列はtinyintであり、null ではなくデフォルトの 0 になります。

SQL サーバー 2008 R2

4

2 に答える 2

1

あなたはあなたの既存の分野が何であるかを言いません。また、「tinyBit」と呼ばれるデータ型はありません。

それでも、2つの考えられる影響のケースがあります。

1）テーブルにすでにビット列が含まれていて、2つのビット列を追加しています

この場合、ビットはパックされたバイトに格納されるため、パフォーマンスの違いはとにかく無視できます。

2）テーブルにビット列が含まれていないか、tinyint列を追加しています

この場合、行ごとに追加情報があるため、パフォーマンスに影響があります。ただし、2,000,000レコードはまったく巨大ではありません。同じ行に余分な列を格納するコストを無効にする簡単な方法INCLUDEは、Col1、Col2、およびCol3列を含むために使用されるインデックスを追加することです。その場合、クエリオプティマイザー（QO）は、コストが低いため、クラスター化インデックスシークではなく、含まれている列を持つインデックスでインデックスシークを選択するのが一般的です。

編集->明確化すると、ケース2）が適用され、関連する列を含むインデックスを作成すると、既存のクラスター化されたシークよりもパフォーマンスが向上する可能性があります。挿入コストが発生するため、それが価値があるかどうかについては、テーブルの読み取り/書き込みバランスに依存します。

于 2012-12-12T15:00:19.350 に答える
1

2M 行のみの場合は、単一のテーブルに保持する必要があると言っても過言ではありません。

MS SQL Server は NULL 値を効率的に格納するため (理想的な状況ではわずか1 ビット)、ストレージの節約を確認するには、多くの列と非常に具体的な NULL 分散が必要になります。

通常、キャッシングの局所性を高めるために垂直分割が行われますが、最近では一般的に 2M 行がメモリに収まるので、そこに違いがあるとは思えません。ただし、JOIN のため、(マイナスの) 違いが見られます。

いずれにせよ、やみくもに何もしないでください。代表的なワークロードを使用して現実的な量のデータを測定し、影響がどのようなものになるかを把握してから決定してください。

于 2012-12-13T14:52:45.473 に答える