web-dev-qa-db-ja.com

テーブルのサイズは重要ですか？

私はこのようなテーブルを持っています（ただし、より多くの列があります）：

CREATE TABLE [dbo].[MyTable](
    [SnapKey] [int] NOT NULL,
    [SnapDt] [smalldatetime] NOT NULL,
    [Company] [varchar](4) NOT NULL,
    [ProfitCenter] [varchar](10) NOT NULL,
    [CostCenter] [varchar](10) NOT NULL,
) ON [MyPartition]([SnapKey])

CREATE CLUSTERED INDEX [IDX1] ON [dbo].[MyTable]
(
    [SnapKey] ASC
)

テーブルは、（（//// =）SnapKey）でpartitionedです。 SnapKeyはSnapDtの日付部分であり、整数として格納されます（20160131や20160229など）。

各パーティションに含まれるSnapKeyは1つだけです。 SnapKeyパーティションごとに、約500万行があります。現在、毎月の最終日のみをテーブルに保持しています。

クエリには常にSnapKeyを使用します。データは更新されません。毎日、データがテーブルに入力され、その月の間にいくつかのレポートが実行されます。

質問：データを1か月あたり1日ではなく、1か月あたり6日間保持すると、クエリのパフォーマンスが低下しますか？

明確な答えが見つからなかったため、テーブルにデータを入力しようとしましたが、ストレージが足りなかったため、理論的な説明がないかどうか確認するように依頼しました。

明確化

さらに5日間保存すると、6回分のデータが保存されます（履歴レポート用）。最終日のみではなく、月末の6日間を保持します。

クエリは変更されず、レポートは1日（SnapKey）のままです。

毎月1つのSnapKeyがあります。今のところ

20160131
20160229
20160330

...等々。月末ごとに1つのSnapKey。

5日以上持つことにより、SnapKeyは次のようになります。

20160126, 20160127, 20160128, 20160129, 20160130, 20160131 
20160224, 20160225, 20160226, 20160227, 20160228, 20160229 
20160325, 20160326, 20160327, 20160328, 20160329, 20160330 ...and so on

6倍以上のデータを保存していますが、クエリではSnapKeyを1つだけ処理しています。これは、私たちが常に持っていることを意味します：

WHERE SnapKey = xxxxxxxx

すべてのクエリで。

sql-serversql-server-2012performancepartitioning
6
user71787

データを月に1日ではなく月に6日間保持すると、クエリのパフォーマンスが低下しますか？

状況によります。

いいえ-以前と同じクエリを正確に実行した場合（新しいデータにはまったくアクセスできません） ）。

SQL Serverのパーティション化実装では、パーティションごとに個別のrowsetが作成されるため、パーティションインデックスを作成すると、個別のBツリー構造*各パーティション（パーティション化されたヒープも存在することに注意してください）。

したがって、単にパーティションを追加しても、既存のパーティションの観点からは何も変更されません。インデックスはまったく同じです。クエリは単一のパーティションのみにアクセスするため、何も変更されません。

Maybe-任意の段階で新しいデータをクエリする場合。新しいデータをメモリに取り込むと、メモリの量によっては、元のクエリで必要なデータが置き換えられる場合があります。変更の結果、新しい物理I/Oが発生する場合は、パフォーマンスに影響があり、重大度はストレージサブシステムの機能によって異なります。

*これは、製品ドキュメントの多くの場所で言及されています。次に例を示します。

それらのリンクから：

クラスタ化インデックスに複数のパーティションがある場合、各パーティションには、その特定のパーティションのデータを含むBツリー構造があります。
非クラスター化インデックスに複数のパーティションがある場合、各パーティションには、その特定のパーティションのインデックス行を含むBツリー構造があります。
ヒープに複数のパーティションがある場合、各パーティションには、その特定のパーティションのデータを含むヒープ構造があります。

sys.partitions のようなシステムカタログビューを見て、hobt_id（ヒープまたはBツリーID）を表示して、これを自分で確認することもできます。特定のパーティションの行を含む構造の。

4
Paul White 9

データを月に1日ではなく月に6日間保持すると、クエリのパフォーマンスが低下しますか？

間違った質問です。はい、それらは遅くなります-インデックスはより深くなり、フィルタリングするためにより多くのデータにアクセスする必要があります。しかし、本当の問題は次のとおりです。インデックス深度の増加は線形ではなく対数であるため、大幅に遅くなるか、少なくとも遅くなりますか。つまりあなたはそれほど多くの新しいレベルを追加しません。

あなたはそれを試す必要があります（理論的な答えに関係なく、メモリの必要性を吹き飛ばし、その倍の量のデータを処理するためにサーバーのアップグレードが必要になる可能性があるため、常に良い考えです）が、それが起こらない限り、そして/またはIO問題...純粋なインデックス付けによって速度が遅くなることはありませんが、すべてをメモリ内に保持するためにメモリが必要になる可能性があります。

メモリが切れた場合は、線形的な速度低下について話します。5倍のデータを読み込むのに5倍の時間がかかります。最良の場合。メモリからディスクに移行することで、パフォーマンスが完全に低下する可能性もあります。あなたは本当にテストケースを作るか、少なくともあなたのメモリサイズをチェックしなければなりません。

1
TomTom